GC_EXTERNAL_ALLOC freed 与 GC_EXPLICIT freed 是什么?

最新推荐文章于 2020-09-23 16:47:50 发布
最新推荐文章于 2020-09-23 16:47:50 发布
阅读量146 收藏
点赞数
文章标签： java
原文链接：https://yq.aliyun.com/articles/400568
版权

09-28 17:16:37.543: DEBUG/dalvikvm(21466): GC_EXTERNAL_ALLOC freed 390 objects / 45656 bytes in 50ms
09-28 17:16:40.513: DEBUG/dalvikvm(3267): GC_EXPLICIT freed 4501 objects / 251624 bytes in 67ms

很多做开发的朋友不明白上面这句是什么意思，给大家解释一下！ 

前面Free的内存是VM中java使用的内存，external是指VM中通过JNI中Native的类中的malloc分配出的内存，例如Bitmap和一些Cursor都是这么分配的。
在Davilk中，给一个程序分配的内存根据机型厂商的不同，而不同，现在的大部分的是32M了，而在VM内部会把这些内存分成java使用的内存和 Native使用的内存，它们之间是不能共享的，就是说当你的Native内存用完了，现在Java又有空闲的内存，这时Native会重新像VM申请，而不是直接使用java的。
例如上边的例子
free 3411K/6663K和external 24870K/26260K
如果这时需要创建一个2M的

Bitmap
，Native现有内存26260-24870=1390K<2048k,因此他就会向Vm申请内存，虽然java空闲的内存是
6663-3411=3252>2048,但这部分内存Native是不能使用。
但是你现在去申请2M的Native内存，VM会告诉你无法分配的，因为现在已使用的内存已经接近峰值了32M(26260+6663=32923 )，所以现在就会成force close 报OOM。
所以现在我们要检查我们的native内存的使用情况来避免OOM。



本文转自java豆子博客园博客，原文链接：http://www.cnblogs.com/error404/archive/2011/09/28/2194708.html，如需转载请自行联系原作者

???Sir
关注
Android D/dalvikvm(4342): GC_FOR_ALLOC freed
码点
03-28 2510
一般Java虚拟机要求支持verbosegc选项，输出详细的垃圾收集调试信息。dalvik虚拟机很安静的接受verbosegc选项，然后什么都不做。dalvik虚拟机使用自己的一套LOG机制来输出调试信息。  如果在Linux下运行adb logcat命令，可以看到如下的输出：  D/dalvikvm(  745): GC_CONCURRENT  free...
内存调试: GC_CONCURRENT freed
面朝大海，春暖花开
06-08 3432
GC_CONCURRENT表示触发垃圾收集的原因，有以下几种： GC_MALLOC, 内存分配失败时触发   GC_CONCURRENT，当分配的对象大小超过384K时触发   GC_EXPLICIT，对垃圾收集的显式调用(System.gc)   GC_EXTERNAL_ALLOC，外部内存分配失败时触发
Heap使用及GC_EXTERNAL_ALLOC含义
钟秀
08-25 3465
一、先说DDMS中的Heap的使用，通过它可以观察VM中的Java内存，但是无法查看通过JNI分配的内存 直接上图，废话少说。。。 图一：将要查看内存使用情况的项目Update heap 图二：操作项目，通过图表可以很直观查看虚拟机的使用内存   二:Andro
GC_EXTERNAL_ALLOC
life02的专栏
09-17 861
09-28 17:16:37.543: DEBUG/dalvikvm(21466): GC_EXTERNAL_ALLOC freed 390 objects / 45656 bytes in 50ms 09-28 17:16:40.513: DEBUG/dalvikvm(3267): GC_EXPLICIT freed 4501 objects / 251624 bytes in 67ms 很多
android gc
hkk101的专栏
09-01 235
GC_EXTERNAL_ALLOC freed 297K, 49% free 3411K/6663K, external 24870K/26260K, paused 83ms是什么意思   前面Free的内存是VM中java使用的内存，external是指VM中通过JNI中Native的类中的malloc分配出的内存，例如Bitmap和一些Cursor都是这么分配的。在Davilk中，给一个程...
android垃圾回收
wangshione的专栏
11-21 1640
GC_EXTERNAL_ALLOC freed 361K, 54% free 2617K/5575K, external 2114K/2137K, paused 169ms GC_EXPLICIT freed 54K, 49% free 2968K/5767K, external 4695K/5802K, paused 76ms 前面Free的内存是VM中java使用的内存，external是
Android内存优化（二）DVM和ART的GC日志分析
Android进阶三部曲 - 刘望舒
06-13 9090
在Java虚拟机（三）垃圾标记算法与Java对象的生命周期这篇文章中，提到了Java虚拟机的GC日志。DVM和ART的GC日志与Java虚拟机的日志有较大的区别，这篇文章就对DVM和ART的GC日志进行分析。
自己编写的一个Activity内存泄漏检测工具
mingC0758的博客
08-09 1236
自己编写的一个Activity内存泄漏检测工具 看完LeakCanary的源码之后，有点想自己动手写一个内存泄漏的工具了，正所谓自己动手，丰衣足食。 真正做起来，其实会出现各种问题，最大的问题就是误判，经常由于GC没有及时把销毁的Activity回收而误判未内存泄漏，即便把检测时间延长也是如此： （这是在两次gc后等待10秒仍然存活的activity，此时仅被虚引用指向） 最后的解决办...
一次内存泄漏的问题记录
lucky_tom的专栏
09-23 1万+
项目场景： 同事在开发一款人脸识别app时，在多次执行，打开--》人脸识别--》关闭--》打开循环测试过程中会耗尽内存。 问题描述： 测试同学通过用monkey脚本测试，遇到OOM内存溢出的问题。 日志片段1：可以看到系统一直在频繁gc，已经超过设定的512mb上限。 09-22 13:53:23.045 3052 3806 I zygote : Waiting for a blocking GC Alloc 09-22 13:53:23.502 3052 5107 I zy...
android GC_CONCURRENT and GC_EXTERNAL_ALLOC
wch.hit的专栏
11-14 1108
内存调试的东西D/dalvikvm( 809 ): GC_CONCURRENT freed 这是一篇介绍安卓虚拟机联网时经常容易报的错误，连接成功后无限下载数据包，永远无法成功的原因。 GC_CONCURRENT  错误：当分配的对象大小超过384K时触发java回收机制，自动回收内容，联网下载的内容在内存中达到这个数时自动清理内存，无限重复下载然后删除的动作，所以这个错误导致
Android中GC_EXTERNAL_ALLOC的含义小结
cw2004100021124的专栏
01-16 876
经常在调试代码的时候，看到GC_EXTERNAL_ALLOC信息。 比如：GC_EXTERNAL_ALLOC freed 297K, 49% free 3411K/6663K, external 24870K/26260K, paused 83ms 这里边的每个数字都是什么意思阿？ 1。其中free 3411K/6663K和external 24870K/26260K,分别都是表示什么？
JVM
zzw1531439090的博客
02-25 700
说明：本系列内容部分转载于他人博客 https://www.cnblogs.com/kivi/p/3197825.html 一、内存模型 从大的方面来讲，JVM的内存模型分为两大块： 永久区内存（ Permanent space ）和堆内存（heap space）。 栈内存（stack space）一般都不归在JVM内存模型中，因为栈内存属于线程级别。 每个线程都有个独立的栈内存空间...
内存调试的东西D/dalvikvm( 809 ): GC_CONCURRENT freed
wangshione的专栏
09-26 3038
GC_CONCURRENT  错误：当分配的对象大小超过384K时触发java回收机制，自动回收内容，联网下载的内容在内存中达到这个数时自动清理内存，无限重复下载然后删除的动作，所以这个错误导致虚拟机无法正常的链接网络。 （注：往往这个错误在实体机上不会发生） 以下是原帖内容： 老是看到LOG日志里有些系
一个GC频繁的Case
Edison Xu
09-23 8163
前两天碰到一个很诡异的GC频繁的现象，走了不少弯路，N种方法查找后才终于查明原因了，在这篇blog中记录下，以便以后碰到这类问题时能更快的解决。 前两天一位同学找到我，说有个应用在启动后就一直Full GC，拿到GC log先看了下，确实是非常的诡异，截取的部分log如下： 2011-07-16T14:55:57.733+0800: 174042.063: [Full GC [PSYoun
spark 2.X 疑难问题汇总
热门推荐
简单就好
12-29 3万+
当前spark任务都是运行在yarn上，所以不用启动长进程worker，也没有master的HA问题，所以主要的问题在任务执行层面。 作业故障分类 故障主要分为版本，内存和权限三方面。 - 各种版本不一致 - 各种内存溢出 - 其他问题 版本不一致 1）java版本不一致 报错：java.lang.UnsupportedClassVersionError: com/im
Java GC G1 详解
勿忘初心
01-02 1万+
G1(Garbage-First)回收器是在JDK1.7中正式使用的全新垃圾回收器，G1拥有独特的垃圾回收策略，从分代上看，G1依然属于分代垃圾回收器，它会区分年代和老年代，依然有eden和survivor区，但从堆的结构上看，它并不要求整个eden区、年清代或者老年代都连续。它使用了全新的分区算法。其特点如下： 并行性：G1在回收期间，可以由多个GC线程同时工作，有效利用多核计算能力。 ...
jar程序运行内存溢出GC overhead limit exceeded
是成长吧
09-19 1849
[code="java"] 这个是JDK6新添的错误类型。是发生在GC占用大量时间为释放很小空间的时候发生的，是一种保护机制。解决方案是，关闭该功能，使用—— -XX:-UseGCOverheadLimit 加载了太多资源到内存，本地的性能也不好，gc时间消耗的较多 这里要查看是否有使用大内存的代码或死循环。 GC overhead limt exceed检查是Hotspot V...
android app卡顿 log分析
最新发布
04-03
<think>好的，我现在要帮助用户分析如何通过log文件解决Android应用卡顿的问题。首先，我需要回顾用户提供的引用内容，看看有哪些工具和方法已经被提到过。根据引用[1]、[3]、[4]、[5]，提到了Traceview、BlockCanary、ANR日志、Systrace和adb命令。这些工具都是分析卡顿的关键。 用户的主要需求是通过日志文件定位卡顿原因。首先，我应该分步骤说明不同的日志类型和工具的使用方法。比如，ANR日志可以直接从设备中获取，分析主线程是否被阻塞。然后，Traceview和Systrace可以帮助分析方法的执行时间和系统层面的性能问题。此外，BlockCanary虽然需要植入代码，但可以监控主线程的耗时操作。 接下来，我需要确保每一步都结合引用内容，并正确标注引用标记。例如，当提到Traceview时，引用[3]详细介绍了它的功能，应该在这里引用。同样，BlockCanary的缺点在引用[2]中提到，需要指出可能的性能影响。 另外，用户可能需要知道如何获取这些日志文件。例如，使用adb命令导出ANR日志（引用[5]），或者通过Systrace生成报告（引用[4]）。需要详细说明每个步骤的操作方法，比如运行什么命令，如何分析结果。 还要注意用户提到的性能开销问题，比如BlockCanary可能会影响应用性能，这在引用[2]中已经说明，应该在建议使用时提到这一点，让用户权衡利弊。 最后，要确保回答结构清晰，分步骤说明，每个部分都有对应的工具和日志分析方法，并结合实际例子，如主线程的堆栈跟踪、GC频繁等常见问题。这样用户能够逐步排查卡顿原因，并找到解决方案。</think>### 通过日志文件分析Android应用卡顿问题的步骤 #### 1. **定位ANR日志** 当应用主线程阻塞超过5秒会触发ANR（Application Not Responding），系统会自动生成`/data/anr/traces.txt`文件，记录主线程堆栈信息： ```bash adb pull /data/anr/traces.txt # 导出ANR日志[^5] ``` 分析重点： - 查找主线程中耗时操作（如同步I/O、复杂计算） - 检查锁竞争或死锁现象 - 识别第三方库的阻塞调用链[^1] #### 2. **使用Traceview进行方法级分析** 通过插桩方式记录方法执行耗时： ```java Debug.startMethodTracing("app_trace"); // 需要监控的代码段 Debug.stopMethodTracing(); ``` 生成`.trace`文件后，使用Android Studio的Profiler加载分析： - 查看主线程调用树中耗时超过16ms的方法（1帧的阈值） - 关注`Wall Clock Time`与`Thread Time`的差异（I/O等待时间） - 识别重复调用的冗余方法[^3] #### 3. **Systrace系统级跟踪** 通过adb采集系统级性能数据： ```bash python systrace.py -a com.example.app -b 16384 -o trace.html gfx view res ``` 分析要点： - 检查`RenderThread`的帧生成间隔 - 观察`Choreographer#doFrame`耗时 - 识别VSYNC信号丢失情况 - 查看GC事件频率（频繁GC会导致卡顿）[^4] ![Systrace帧渲染分析示意图][^4] #### 4. **BlockCanary自动化检测** 在build.gradle中添加依赖后实现拦截器： ```java public class AppBlockCanary extends BlockCanaryContext { // 配置检测阈值和日志路径 } ``` 监控结果包含： - 卡顿时主线程堆栈快照 - 耗时操作的代码位置 - 关联的IPC调用信息[^2] #### 5. **Logcat日志过滤** 通过特定标签过滤关键信息： ```bash adb logcat -v time -s Choreographer:W ActivityManager:I *:S ``` 重点关注： ``` W/Choreographer: Skipped 3 frames! The application may be doing too much work on its main thread I/ActivityManager: ANR in com.example.app ``` #### 6. **GC日志分析** 在应用启动参数中添加： ```bash adb shell setprop log.tag.Gc DEBUG ``` 检查日志中的GC原因： ``` D/art: Explicit concurrent mark sweep GC freed... D/art: Alloc concurrent mark sweep GC freed... ``` 频繁GC（每秒超过1次）可能说明存在内存抖动[^1] ### 典型卡顿场景解决方案 1. **布局过度绘制** - 使用`Layout Inspector`检查视图层级 - 替换`RelativeLayout`为`ConstraintLayout` - 启用`GPU过度绘制调试`（设置-开发者选项） 2. **主线程IO操作** ```java new Thread(() -> { // 文件操作移至子线程 }).start(); ``` 3. **内存泄漏检测** ```bash adb shell dumpsys meminfo com.example.app -d ``` $$ T_{frame} = T_{input} + T_{measure} + T_{layout} + T_{draw} \leq 16ms $$
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值