GC调优技术--Mirror 中的使用

最新推荐文章于 2025-05-11 10:22:57 发布
原创 最新推荐文章于 2025-05-11 10:22:57 发布 · 366 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

一

IT___zhao
关注
Mirror：Mirror基础操作与使用
kkchenjj的博客
09-27 905
通过以上步骤，你可以成功地在Unity项目中搭建Mirror环境，并配置基本的网络同步。接下来，你可以进一步探索Mirror的高级特性，如网络优化、延迟补偿等，以提升你的多人游戏体验。注意：以上内容和代码示例是基于Mirror框架的基本使用，具体实现可能需要根据你的游戏需求进行调整。在开发过程中，建议参考Mirror的官方文档和社区资源，以获取更详细的指导和帮助。在Mirror网络框架中，自定义网络消息是实现复杂网络交互的关键。
mirror gc和gc
NIUBILISI的博客
08-19 1332
Mirror gc:指的是回收新生代，因为新生代对象存活时间很短，因此会频繁执行。 Full gc:指的是回收新生代和老年代。 GC触发条件 因为对象优先在Eden区分配，因此Eden区空间不足时，就会触发Mirror gc。会进入老年代的对象包括：一些大对象，比如很长的字符串和连续的数组会直接进入老年代；还有对象在survivor每存活过一个gc后年龄就会加1，当达到一定年龄后就会进入老年代；还...
JVM知识整合
beiduofen2011的专栏
01-06 229
1、作用：解析字节码文件（class文件），转化成相应操作系统执行的机器指令并提交执行 输入:class文件，输出：相应操作系统的机器指令
JVM学习笔记
1024
03-07 696
Java虚拟机学习笔记 GC（Garbage Collection） Java和JVM的历史 1996年 SUN JDK 1.0 Classic VM，纯解释运行，使用外挂进行JIT 1997年 JDK1.1 发布，AWT、内部类、JDBC、RMI、反射 1998年 JDK1.2 Solaris Exact VM JIT 解释器混合 ，Accurate Memory Management...
JVM虚拟机 之 GC收集器(垃圾收集器)
Right.W
03-19 484
首先来概括一下有哪些垃圾收集器,并且他们各自适用于什么代,采用什么回收算法: 新生代：Serial收集器、ParNew收集器、Parallel Scavenge收集器。 老年代：Serial Old收集器、Parallel Old收集器、CMS收集器。 新生代由于每次收集都会有大量对象死去，所以采用复制算法；而老年代的对象存活几率是较高的，没有额外的空间对它进行分配担保，这里采用标记-整理...
Mirror 的工作原理
weixin_33851177的博客
11-15 2008
作者：Mike Ash，原文链接，原文日期：2018-09-26 译者：Nemocdz；校对：numbbbbb，小铁匠Linus；定稿：Forelax 尽管 Swift 重心在强调静态类型上，但它同时支持丰富的元数据类型。元数据类型允许代码在运行时检查和操作任意值。这个功能通过 Mirror API 暴露给 Swift 开发者。大家可能会感到困惑，在 Swift 这种如此强调静态类型的语言...
大数据场景下RabbitMQ的性能调优指南
大数据洞察的博客
05-11 1341
在大数据处理场景中，RabbitMQ作为轻量级消息中间件，常面临每秒万级以上的消息吞吐量、毫秒级延迟要求和复杂的集群容错需求。本文聚焦网络IO优化内存与磁盘资源调度消费者负载均衡持久化策略调优四大核心维度，提供从客户端到服务端的全栈性能优化方案。目标读者包括分布式系统架构师、中间件开发工程师及大数据平台运维人员。基础概念与性能瓶颈分析核心调优维度的数学建模与算法实现从单机到集群的配置实践典型场景的优化案例与工具链Channel（通道）
tomcat 8 9 性能 优化 调优 centos 7 linux
张震的博客
06-20 5675
tomcat 调优，优化，配置。
Apache Pulsar 在 BIGO 的性能调优实战（上）
weixin_52652808的博客
03-01 982
在人工智能技术的支持下，BIGO 基于视频的产品和服务受到广泛欢迎，在 150 多个国家/地区拥有用户，其中包括 Bigo Live（直播）和 Likee（短视频）。Bigo Live 在 150 多个国家/地区兴起，Likee 有 1 亿多用户，并在 Z 世代中很受欢迎。...
rancher部署Kubernetes集群之基础环境docker-ce部署
山东梅长苏
08-27 1057
概述 What’s Rancher？ Rancher是一套容器管理平台，它可以帮助组织在生产环境中轻松快捷的部署和管理容器。 Rancher可以轻松地管理各种环境的Kubernetes，满足IT需求并为DevOps团队提供支持。 Kubernetes不仅已经成为的容器编排标准，它也正在迅速成为各类云和虚拟化厂商提供的标准基础架构。Rancher用户可以选择使用Rancher Kubernetes ...
3.1.4 YARN资源调度、Apache Hadoop 核心源码剖析、调优、Hadoop二次开发
weixin_47134119的博客
01-27 1793
3.1.4 YARN资源调度、Apache Hadoop 核心源码剖析 文章目录3.1.4 YARN资源调度、Apache Hadoop 核心源码剖析七、YARN资源调度7.1 Yarn架构7.2 Yarn任务提交(工作机制)7.3 Yarn调度策略7.4Yarn多租户资源隔离配置八、Apache Hadoop 核心源码剖析8.1 源码阅读准备8.2 NameNode 启动流程 七、YARN资源调度 7.1 Yarn架构 ResourceManager(rm)：处理客户端请求、启动/监控Ap
浅谈jvm的GC
angelbabyfalse的博客
06-20 270
GC是什么? GC英文全称为grabage collection,因为java是运行在jvm上的，而jvm分配对象时再堆上分配，当jvm想要分配对象而堆空间不够时就会触发GC。 哪些是GC对象。 GC的对象时那些不在被需要的对象，可以称其为死亡对象。判断一个对象是否死亡有两种方法。一种是引用计数法，，每个对象有一个引用计数器，当它被应用就把计数器加一，当取消对它的应用就把计数...
JVM GC简介
u012002125的博客
07-02 610
JVM GC简介 GC名词解释 GC：Gabage Collection，指JVM堆内存区域的垃圾回收 Minor GC：也叫Young GC,年轻代垃圾回收 Major GC：也叫Full GC，年老代垃圾回收 年轻代和年老代的GC策略是不一样的，年轻代一般采用的是复制算法。 JVM内存模型 JVM的内存空间分为：新生代空间(Young)和老年代空间（Old）。新生代空间（Young）又被分为2个部分（Eden区域、Survivous区域）和3个板块（1个Eden区域和2个Survivo
Java垃圾回收机制（GC原理）解析
java521666的博客
07-11 6220
Java相比于c/c++一个最显著的特征就是引入了垃圾回收机制，使我们不用像c/c++编写时还要注意内存管理，java中JVM替我们完成了这部分工作
JVM: GC过程总结(minor GC 和 Full GC)
热门推荐
weixin_42615068的博客
10-30 3万+
一 minorGC 和 Full GC区别 新生代 GC（Minor GC）:指发生新生代的的垃圾收集动作，Minor GC 非常频繁，回收速度一般也比较快。 老年代 GC（Major GC/Full GC）:指发生在老年代的 GC，出现了 Major GC 经常会伴随至少一次的 Minor GC（并非绝对），Major GC 的速度一般会比 Minor GC 的慢 10 倍以上。 二...
Java GC - 垃圾回收机制
weixin_33772645的博客
12-06 149
1、简介 对于Java developer来说，了解JVM GC工作原理能够帮助我们开发出更优秀的应用，同时在处理JVM瓶颈时能够更加自由。在最近一年的应用开发中能体会到这些知识带来的好处，并且让我们的应用在较大规模的并发时能够良好的工作。 本文部分知识和图片来源于书籍《Java Performance》 -Charlie Hunt & Binu John 著，该书全...
Maven：mirror和repository 区别
caomiao2006的专栏
10-23 1万+
internal repository是指在局域网内部搭建的repository，它跟central repository, jboss repository等的区别仅仅在于其URL是一个内部网址  mirror则相当于一个代理，它会拦截去指定的远程repository下载构件的请求，然后从自己这里找出构件回送给客户端。配置mirror的目的一般是出于网速考虑。  可以看出，internal
这是源代码oid Verification::LogHeapCorruption(ObjPtr<mirror::Object> holder, 96 MemberOffset offset, 97 mirror::Object* ref, 98 bool fatal) const { 99 // Highest priority logging first. 100 // Buffer the output in the string stream since it is more important than the stack traces 101 // and we want it to have log priority. The stack traces are printed from Runtime::Abort 102 // which is called from LOG(FATAL) but before the abort message. 103 std::ostringstream oss; 104 oss << "GC tried to mark invalid reference " << ref << std::endl; 105 oss << DumpObjectInfo(ref, "ref") << "\n"; 106 oss << DumpObjectInfo(holder.Ptr(), "holder") << "\n"; 107 if (holder != nullptr) { 108 mirror::Class* holder_klass = holder->GetClass<kVerifyNone, kWithoutReadBarrier>(); 109 if (IsValidClass(holder_klass)) { 110 oss << " field_offset=" << offset.Uint32Value(); 111 ArtField* field = holder->FindFieldByOffset(offset); 112 if (field != nullptr) { 113 oss << " name=" << field->GetName(); 114 } 115 } 116 mirror::HeapReference<mirror::Object>* addr = holder->GetFieldObjectReferenceAddr(offset); 117 oss << " reference addr" 118 << DumpRAMAroundAddress(reinterpret_cast<uintptr_t>(addr), 4 * kObjectAlignment); 119 } 120 Runtime::Current()->GetHeap()->DumpSpaces(oss); 121 MemMap::DumpMaps(oss, /* terse= */ true); 122 123 if (fatal) { 124 LOG(FATAL) << oss.str(); 125 } else { 126 LOG(FATAL_WITHOUT_ABORT) << oss.str(); 127 } 128 } 129
最新发布
12-11
<think>我们正在分析Android ART虚拟机中的错误日志，特别是与垃圾回收（GC）相关的错误“GC tried to mark invalid reference 0xffffffff”。用户要求结合错误日志分析`Verification::LogHeapCorruption`函数的作用，并探讨错误产生的原因。 首先，回顾错误日志： 日志中出现了多次`verification.cc:124]`，这表示错误发生在`verification.cc`文件的第124行，该行代码属于`Verification::LogHeapCorruption`函数。 根据ART虚拟机的源代码（以Android 12为例），我们可以分析该函数的作用： 1. **函数作用**： `Verification::LogHeapCorruption`函数用于记录堆损坏（Heap Corruption）的详细信息。当GC在标记阶段遇到无效引用（如空指针、已释放对象、非对象地址等）时，会调用此函数记录错误上下文，包括： - 无效引用的地址（如0xffffffff） - 持有该引用的对象地址和类型（如holder=0x2ed9988, klass=0x2354c00 (java.lang.Class<com.coui.appcompat.textview.COUITextView>)） - 引用的字段信息（如field_offset=780, name=mSpannable） - 堆空间信息（如Bump pointer space, ImageSpace, ZygoteSpace等） 该函数还会打印出各个内存空间的详细信息（地址范围、位图等），帮助开发者定位内存损坏的位置。 2. **错误日志分析**： 在给定的日志中，GC在标记阶段发现一个无效引用0xffffffff（通常表示空指针或无效内存地址）。该引用属于一个COUITextView对象的mSpannable字段（偏移780）。日志详细列出了堆空间的状态，包括： - Bump pointer space（年轻代空间） - 多个ImageSpace（系统镜像空间） - Zygote space（Zygote进程共享空间） - Non moving space（老年代空间） - Large object space（大对象空间） 这些信息表明，GC在标记过程中遇到了一个无效引用，而该引用位于一个COUITextView对象中。可能的原因是： - 该对象已经被释放（成为悬挂指针），但仍有引用指向它。 - 内存被覆盖，导致对象引用被破坏。 - 多线程并发问题，在GC标记的同时，对象被其他线程修改。 3. **错误产生原因推测**： 结合日志和函数作用，错误可能由以下原因引起： a. **对象提前释放**：在GC标记开始前，该COUITextView对象被错误释放，导致其引用变为无效（0xffffffff）。这可能是由于JNI代码错误地调用了`DeleteGlobalRef`，或是Java层代码持有了一个已经回收的弱引用。 b. **堆内存破坏**：其他内存写操作越界（如JNI数组操作越界、本地代码缓冲区溢出）覆盖了该对象的mSpannable字段，将其设置为无效值。 c. **并发问题**：在并发标记阶段（如ART的CMS GC），应用线程修改了对象引用，而GC线程未能正确同步，导致标记时引用失效。 d. **自定义ROM或框架BUG**：日志中出现了`com.coui.appcompat.textview.COUITextView`，这是COUI（可能是ColorOS或OPPO的自定义UI）的控件。该自定义控件可能存在内存管理缺陷。 4. **解决方案建议**： - **检查JNI代码**：如果应用使用了JNI，仔细检查所有对COUITextView对象的操作，确保没有过早释放引用或越界访问。 - **使用内存分析工具**：利用Android Studio的Memory Profiler或Valgrind（针对native代码）检测内存泄漏和越界访问。 - **更新自定义控件**：如果COUITextView是第三方库的一部分，更新到最新版本或联系供应商修复。 - **调整GC参数**：如之前建议，尝试添加`-XX:+CMSScavengeBeforeRemark`参数，在最终标记前执行Young GC，减少无效引用。 - **启用ART的堆验证**：在开发版本中，可以通过设置系统属性`dalvik.vm.enable_heap_verification`为1来启用堆验证，在每次GC时检查堆的完整性（但会影响性能）。 5. **源代码层面分析**： 我们可以在ART源码中找到`verification.cc`中的`LogHeapCorruption`函数（以Android 12源码为例）： ```cpp void Verification::LogHeapCorruption(ObjPtr<mirror::Object> holder, MemberOffset offset, mirror::Object* ref, bool fatal) { // ... 构建错误信息 ... std::ostringstream oss; oss << (fatal ? "GC tried to " : "Could not ") << "mark invalid reference " << ref << "\n" << "ref=" << ref << " " << (ref == nullptr ? "null" : "invalid address") << "\n" << "holder=" << holder.Ptr() << " " << (holder == nullptr ? "null" : holder->PrettyTypeOf()) << " "; if (holder != nullptr) { oss << "field_offset=" << offset.Uint32Value() << " " << GetFieldName(holder, offset); } // 打印堆空间信息 Runtime::Current()->GetHeap()->DumpSpaces(oss); LOG(fatal ? FATAL : ERROR) << oss.str(); } ``` 该函数在检测到堆损坏时被调用，参数`fatal`决定是否终止进程（日志中为F级别，即会终止进程）。在日志中，我们看到该函数输出了holder对象、字段偏移、引用地址以及堆空间信息。 6. **结论**： 错误日志表明ART虚拟机在GC标记阶段检测到堆内存损坏，具体是一个COUITextView对象的mSpannable字段包含无效引用0xffffffff。这通常由内存管理错误引起，需要结合代码和工具进一步排查。 §§相关问题§§ 1. ART虚拟机中垃圾回收的标记阶段是如何工作的？ 2. 如何通过Android Studio检测和修复内存泄漏？ 3. JNI编程中如何正确管理全局引用和局部引用以避免内存问题？ </think> ### `Verification::LogHeapCorruption` 函数作用与错误日志分析 #### 1. **`LogHeapCorruption` 函数的核心作用** 在 ART（Android Runtime）源代码中，`Verification::LogHeapCorruption` 是用于**检测和报告堆内存损坏**的关键函数。其核心功能包括： - **检测无效引用**：当 GC 尝试标记对象引用时，若发现引用地址无效（如 `0xffffffff` 表示空指针或未初始化地址），会触发此函数。 - **输出诊断信息**：记录包含以下关键信息： - 持有引用的对象地址（`holder=0x2ed9988`） - 对象类型（`klass=0x2354c00`，即 `COUITextView`） - 引用字段偏移量和名称（`field_offset=780, name=mSpannable`） - 堆空间详细信息（如 Bump pointer space、ImageSpace、ZygoteSpace 的地址范围） - **终止进程**：由于堆损坏可能导致系统不稳定，该函数最终会调用 `LOG(FATAL)` 终止进程（日志中的 `F` 表示 Fatal 错误）[^1]。 #### 2. **错误日志与函数调用的关联分析** 从日志 `verification.cc:124] GC tried to mark invalid reference 0xffffffff` 可明确看出： - **触发位置**：错误发生在 `verification.cc` 文件的第 124 行，即 `LogHeapCorruption` 函数内部。 - **关键参数解析**： | 日志字段 | 含义 | 示例值 | |----------|------|--------| | `ref` | 无效引用地址 | `0xffffffff` | | `holder` | 持有该引用的对象 | `0x2ed9988` | | `klass` | 对象类型 | `java.lang.Class<COUITextView>` | | `field_offset` | 字段在对象中的偏移量 | `780`（对应 `mSpannable` 字段） | | `space` | 堆空间类型 | `Bump pointer space`（新生代） | - **堆空间状态**： ```log 0xb4000071eee6f610 bump-pointer space live bitmap[begin=0x2000000,end=0x1a000000] 0xb4000071eeec1100 SpaceTypeImageSpace begin=0x5a669000,... // 系统镜像空间 0xb4000071eee73400 SpaceTypeImageSpace begin=0x6f48c000,... // boot.art 空间 ``` 显示 GC 正在扫描多个堆空间，但无法在**新生代（Bump pointer space）** 中找到有效的对象引用。 #### 3. **错误根本原因分析** 结合日志和函数行为，错误可能由以下原因导致： 1. **对象提前释放** `COUITextView` 对象的 `mSpannable` 字段被引用时，其指向的对象**已被 GC 回收**（如 JNI 代码错误调用 `DeleteGlobalRef`）。 当 GC 尝试标记该引用时，地址 `0xffffffff` 表示对象已无效。 2. **内存越界写入** JNI 代码或本地库发生**缓冲区溢出**，覆盖了 `COUITextView` 对象在堆中的内存布局，导致字段值被篡改为无效地址： ```c // 伪代码示例：JNI 越界写入破坏对象 jintArray array = (*env)->NewIntArray(env, 10); jint* elements = (*env)->GetIntArrayElements(env, array, NULL); elements[15] = 0xFFFFFFFF; // 越界写入！可能破坏相邻对象 ``` 3. **并发访问冲突** 在 GC 的**并发标记阶段**，若主线程修改了 `COUITextView.mSpannable` 的引用（如设为 `null`），而 GC 线程同时尝试标记该字段，会导致地址失效。 4. **堆空间管理异常** 日志中 `Bump pointer space`（新生代）的对象引用指向无效地址，表明： - 对象可能被错误移动到其他堆空间（如晋升到老年代），但引用未更新。 - 堆内存碎片化导致地址映射错误。 #### 4. **解决方案建议** 1. **启用堆验证工具** 在 `adb` 中激活 ART 的堆验证功能，定位损坏对象： ```bash adb shell setprop dalvik.vm.enable_heap_verification 1 adb shell stop && adb shell start # 重启 ART ``` 2. **检查 JNI 代码** 重点审查 `COUITextView` 相关的本地代码： - 确保全局引用（`jobject`）使用 `NewGlobalRef`/`DeleteGlobalRef` 配对。 - 避免跨线程操作 Java 对象（需用 `AttachCurrentThread`）。 3. **内存分析工具** 使用 Android Studio 的 **Memory Profiler** 或 **Valgrind** 检测： - 对象生命周期异常 - 堆空间地址越界写入 4. **GC 参数调优** 在 `system.prop` 中添加参数，减少并发标记冲突： ```properties dalvik.vm.gctype = CMS dalvik.vm.extra-opts = -XX:ParallelGCThreads=2 -XX:+CMSScavengeBeforeRemark ``` #### 5. **总结** `LogHeapCorruption` 是 ART 的堆损坏防护机制，错误日志表明 `COUITextView.mSpannable` 字段引用了无效内存。根本原因集中在**对象生命周期管理错误**或**内存越界**，需结合 JNI 审查和堆分析工具解决[^1]。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值