精华内容
下载资源
问答
  • GC(Allocation Failure)引发的一些JVM知识点梳理

    万次阅读 多人点赞 2018-10-12 17:08:51
    日前查看某个程序的日志,发现一直在报GC相关的信息,不确定这样的信息是代表正确还是不...[GC (Allocation Failure) [ParNew: 367523K->1293K(410432K), 0.0023988 secs] 522739K->156516K(1322496K), 0.0025...

    日前查看某个程序的日志,发现一直在报GC相关的信息,不确定这样的信息是代表正确还是不正确,所以正好借此机会再复习下GC相关的内容:

    以其中一行为例来解读下日志信息:

    [GC (Allocation Failure) [ParNew: 367523K->1293K(410432K), 0.0023988 secs] 522739K->156516K(1322496K), 0.0025301 secs] [Times: user=0.04 sys=0.00, real=0.01 secs]

     

    GC

    表明进行了一次垃圾回收,前面没有Full修饰,表明这是一次Minor GC ,注意它不表示只GC新生代,并且现有的不管是新生代还是老年代都会STW

    Allocation Failure

    表明本次引起GC的原因是因为在年轻代中没有足够的空间能够存储新的数据了。

    ParNew

        表明本次GC发生在年轻代并且使用的是ParNew垃圾收集器。ParNew是一个Serial收集器的多线程版本,会使用多个CPU和线程完成垃圾收集工作(默认使用的线程数和CPU数相同,可以使用-XX:ParallelGCThreads参数限制)。该收集器采用复制算法回收内存,期间会停止其他工作线程,即Stop The World。

    367523K->1293K(410432K):单位是KB

    三个参数分别为:GC前该内存区域(这里是年轻代)使用容量,GC后该内存区域使用容量,该内存区域总容量。

    0.0023988 secs

        该内存区域GC耗时,单位是秒

    522739K->156516K(1322496K)

    三个参数分别为:堆区垃圾回收前的大小,堆区垃圾回收后的大小,堆区总大小。

    0.0025301 secs

    该内存区域GC耗时,单位是秒

    [Times: user=0.04 sys=0.00, real=0.01 secs]

        分别表示用户态耗时,内核态耗时和总耗时

     

    分析下可以得出结论:

        该次GC新生代减少了367523-1293=366239K

        Heap区总共减少了522739-156516=366223K

        366239 – 366223 =16K,说明该次共有16K内存从年轻代移到了老年代,可以看出来数量并不多,说明都是生命周期短的对象,只是这种对象有很多。

        我们需要的是尽量避免Full GC的发生,让对象尽可能的在年轻代就回收掉,所以这里可以稍微增加一点年轻代的大小,让那17K的数据也保存在年轻代中。

     

    GC时,什么方法判断哪些对象需要回收:

    1. 引用计数法(已经不用了)
    2. 可达性分析法

    前一种简而言之就是给对象添加一个引用计数器,有其他地方引用时这个计数器+1,引用失效时-1,为0时就可以删除掉了。但是它不能解决循环引用的问题,所以一般使用的都是后一种算法。

    可达性分析法的基本思路就是通过一系列名为GC Roots的对象作为起始点,从这些节点开始向下搜索,搜索所走过的路径称为引用链(Reference Chain),当一个对象到GC Roots没有任何引用链相连时,则证明此对象是不可用的,那就可以回收掉了。

    GC Roots一般都是些堆外指向堆内的引用,例如:

    1. JVM栈中引用的对象
    2. 方法区中静态属性引用的对象
    3. 方法区中常量引用的对象
    4. 本地方法栈中引用的对象 

     

     

    以CMS为例,补充一些知识点介绍:

    复制算法介绍:

    因为新生代对象生命周期一般很短,现在一般将该内存区域划分为三块部分,一块大的叫Eden,两块小的叫Survivor。他们之间的比例一般为8:1:1。

    使用的时候只使用Eden + 一块Survivor。用Eden区用满时会进行一次minor gc,将存活下面的对象复制到另外一块Survivor上。如果另一块Survivor放不下(对应虚拟机参数为 XX:TargetSurvivorRatio默认50,50%),对象直接进入老年代

    (使用CMS时,默认的新生代收集器是ParNew)(有时新生代GC时,需要找到老年代中引用的新生代对象,这个时候会用到一种叫“卡表”的技术,避免老年代的全表扫描,具体怎么操作的暂时还不知道……)

     

    Survivor区的意义:

        如果没有survivor,Eden每进行一次minor gc,存活的对象就会进入老年代,老年代很快被填满就会进入major gc。由于老年代空间一般很大,所以进行一次gc耗时要长的多!尤其是频繁进行full GC,对程序的响应和连接都会有影响!

        Survivor存在就是减少被送到老年代的对象,进而减少Full gc的发生。默认设置是经历了15次minor gc还在新生代中存活的对象才会被送到老年代。

     

    为什么要有两个Survivor:

        主要是为了解决内存碎片化和效率问题。如果只有一个Survivor时,每触发一次minor gc都会有数据从Eden放到Survivor,一直这样循环下去。注意的是,Survivor区也会进行垃圾回收,这样就会出现内存碎片化问题。如下图所示:

     

        碎片化会导致堆中可能没有足够大的连续空间存放一个大对象,影响程序性能。如果有两块Survivor就能将剩余对象集中到其中一块Survivor上,避免碎片问题。如下图所示:

     

    Minor GC和Full GC的区别以及触发条件:

    Minor GC:

        对于复制算法来说,当年轻代Eden区域满的时候会触发一次Minor GC,将Eden和From Survivor的对象复制到另外一块To Survivor上。

        注意:如果某个对象存活的时间超过一定Minor gc次数会直接进入老年代,不在分配到To Survivor上(默认15次,对应虚拟机参数 -XX:+MaxTenuringThreshold)。

     

    Full GC:

    用于清理整个堆空间。它的触发条件主要有以下几种:

    1. 显式调用System.gc方法(建议JVM触发)。
    2. 方法区空间不足(JDK8及之后不会有这种情况了,详见下文)
    3. 老年代空间不足,引起Full GC。这种情况比较复杂,有以下几种:

    3.1 大对象直接进入老年代引起,由-XX:PretenureSizeThreshold参数定义

    3.2 Minor GC时,经历过多次Minor GC仍存在的对象进入老年代。上面提过,由-XX:MaxTenuringThreashold参数定义

    3.3 Minor GC时,动态对象年龄判定机制会将对象提前转移老年代。年龄从小到大进行累加,当加入某个年龄段后,累加和超过survivor区域 * -XX:TargetSurvivorRatio的时候,从这个年龄段往上的年龄的对象进入老年代

    3.4 Minor GC时,Eden和From Space区向To Space区复制时,大于To Space区可用内存,会直接把对象转移到老年代

     

    JVM的空间分配担保机制可能会触发Full GC:

    在进行Minor GC之前,JVM的空间担保分配机制可能会触发3.2、3.3和3.4发生,即触发一次Full GC。

    空间担保分配是指在发生Minor GC之前,虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。

    如果大于,则此次Minor GC是安全的。

    如果小于,则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果HandlePromotionFailure=true,那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小,如果大于,则尝试进行一次Minor GC,但这次Minor GC依然是有风险的,失败后会重新发起一次Full gc;如果小于或者HandlePromotionFailure=false,则改为直接进行一次Full GC。

    所有才会说一次Full GC很有可能是由一次Minor GC触发的。

     

    PS:JDK8中HotSpot为什么要取消永久代

        JDK8取消了永久代,新增了一个叫元空间(Metaspace)的区域,对应的还是JVM规范中的方法区(主要存放一些class和元数据的信息)。区别在于元空间使用的并不是JVM中的内存,而是使用本地内存

        而这么做的原因大致有以下几点:

           1、字符串存在永久代中,容易出现性能问题和内存溢出。

      2、类及方法的信息等比较难确定其大小,因此对于永久代的大小指定比较困难,太小容易出现永久代溢出,太大则容易导致老年代溢出。

      3、永久代会为 GC 带来不必要的复杂度,并且回收效率偏低。

      4、Oracle 可能会将HotSpot 与 JRockit 合二为一。

     

    补充下JDK8内存模型图:

     

     

     

     

    参考:

     

    https://blog.csdn.net/antony9118/article/details/51425581(两个Survivor的意义)

    https://zhidao.baidu.com/question/1111800566588999699.html(Full GC什么时候触发)

    https://blog.csdn.net/l1394049664/article/details/81486470#%E4%BA%94%E3%80%81java8%E5%86%85%E5%AD%98%E6%A8%A1%E5%9E%8B%E5%9B%BE(JDK8内存模型图)

    https://blog.csdn.net/quinnnorris/article/details/75040538(可达性分析算法解析)

    https://segmentfault.com/a/1190000007726689(卡表是什么)

     

     

    展开全文
  • Asset Allocation

    2020-11-22 02:12:21
    <p>Asset Allocation items (in the list above) contain basically just one number - the percentage allocation (i.e. govt. bonds = 10%, international shares = 13%). So, technically, this is a new...
  • <p>This can typically happen if the first (victim) allocation is large (e.g. for a ZIL block) and the concurrent allocation is small. The smaller allocation may be able to find enough contiguous space...
  • Memory Allocation

    2020-12-02 04:43:41
    When tou do so, a double allocation is made, one for the entity by the new call, and one for a control block. Reading large ifc files this is time consuming. If you use std::make_shared, only one ...
  • Allocation examples

    2021-01-11 13:56:52
    <div><p>Hey, I would like to add examples of Allocation, is that possible?</p><p>该提问来源于开源项目:mmcgrana/gobyexample</p></div>
  • AutoID allocation

    2020-12-09 05:15:38
    <div><p>ID auto allocation is good idea, sorry for bad english.</p><p>该提问来源于开源项目:FlansMods/FlansMod</p></div>
  • Memory allocation

    2021-01-11 02:41:23
    <div><ul><li>Test for NULL after allocation</li><li>Use of calloc instead of malloc</li></ul>该提问来源于开源项目:commonmark/commonmark-spec</p></div>
  • Pause allocation

    2020-12-08 22:47:50
    <div><p>Add ability to pause auto allocation process until a sensor is active. Start adding some real tests to the autodispatcher. <h1>6253</h1><p>该提问来源于开源项目:JMRI/JMRI</p></div>
  • Independent allocation

    2021-01-02 21:30:28
    <div><p>Catherine West mentions a crucial missing feature, independent allocation in her RustConf talk, as mentioned to me: <p>https://youtu.be/aKLntZcp27M?t=2026 <p>Could you elaborate what ...
  • <div><ul><li>Introduce allocation service API for enabling multi-cluster allocations.</li><li>Implementing the logic to choose between local or remove allocation to be applied. (remote allocation is ...
  • Bad allocation

    2020-12-27 16:04:55
    <div><p>for (int i = 0; i < 1000000; i++) { AbstractState f = AbstractState.factory("...bad allocation" exception.</p><p>该提问来源于开源项目:CoolProp/CoolProp</p></div>
  • Reduce allocation

    2021-01-02 00:21:39
    <div><p>The fluent API is currently very allocation-intensive. It could be possible to reduce allocations by e.g. changing the arguments of <code>format</code> from <code>HashMap<&'a str, ...
  • Allocation Rate和GC(Allocation Failure) Allocation Rate, 翻译为分配速率, 而不是分配率; 因为不是百分比,而是单位时间内分配的量; 高分配速率(High Allocation Rate) 分配速率(Allocation rate)表示单位时间...

                        Allocation Rate和GC(Allocation Failure)


    Allocation Rate, 翻译为分配速率, 而不是分配率; 因为不是百分比,而是单位时间内分配的量;

    高分配速率(High Allocation Rate)

    分配速率(Allocation rate)表示单位时间内分配的内存量。通常使用 MB/sec作为单位, 也可以使用 PB/year 等。

    分配速率过高就会严重影响程序的性能。在JVM中会导致巨大的GC开销。

    如何测量分配速率?

    指定JVM参数: -XX:+PrintGCDetails -XX:+PrintGCTimeStamps , 通过GC日志来计算分配速率. GC日志如下所示:

    0.291: [GC (Allocation Failure) 
    		[PSYoungGen: 33280K->5088K(38400K)] 
    		33280K->24360K(125952K), 0.0365286 secs] 
    	[Times: user=0.11 sys=0.02, real=0.04 secs] 
    0.446: [GC (Allocation Failure) 
    		[PSYoungGen: 38368K->5120K(71680K)] 
    		57640K->46240K(159232K), 0.0456796 secs] 
    	[Times: user=0.15 sys=0.02, real=0.04 secs] 
    0.829: [GC (Allocation Failure) 
    		[PSYoungGen: 71680K->5120K(71680K)] 
    		112800K->81912K(159232K), 0.0861795 secs] 
    	[Times: user=0.23 sys=0.03, real=0.09 secs]

    计算 上一次垃圾收集之后,与下一次GC开始之前的年轻代使用量, 两者的差值除以时间,就是分配速率。 通过上面的日志, 可以计算出以下信息:

    1. JVM启动之后 291ms, 共创建了 33,280 KB 的对象。 第一次 Minor GC(小型GC) 完成后, 年轻代中还有 5,088 KB 的对象存活。
    2. 在启动之后 446 ms, 年轻代的使用量增加到 38,368 KB, 触发第二次GC, 完成后年轻代的使用量减少到 5,120 KB
    3. 在启动之后 829 ms, 年轻代的使用量为 71,680 KB, GC后变为 5,120 KB

    可以通过年轻代的使用量来计算分配速率, 如下表所示:

    Event Time Young before Young after Allocated during Allocation rate
    1st GC 291ms 33,280KB 5,088KB 33,280KB 114MB/sec
    2nd GC 446ms 38,368KB 5,120KB 33,280KB 215MB/sec
    3rd GC 829ms 71,680KB 5,120KB 66,560KB 174MB/sec
    Total 829ms N/A N/A 133,120KB 161MB/sec

    通过这些信息可以知道, 在测量期间, 该程序的内存分配速率为 161 MB/sec

    分配速率的意义

    分配速率的变化,会增加或降低GC暂停的频率, 从而影响吞吐量。 但只有年轻代的 minor GC 受分配速率的影响, 老年代GC的频率和持续时间不受 分配速率(allocation rate)的直接影响, 而是受到 提升速率(promotion rate)的影响。
    在得出 “Eden区越大越好” 这个结论前, 我们注意到, 分配速率可能会,也可能不会影响程序的实际吞吐量。 吞吐量和分配速率有一定关系, 因为分配速率会影响 minor GC 暂停, 但对于总体吞吐量的影响, 还要考虑 Major GC(大型GC)暂停, 而且吞吐量的单位不是 MB/秒, 而是系统所处理的业务量。

    高分配速率对JVM的影响

    首先,我们应该检查程序的吞吐量是否降低。如果创建了过多的临时对象, minor GC的次数就会增加。如果并发较大, 则GC可能会严重影响吞吐量。
     

    解决方案

    在某些情况下,只要增加年轻代的大小, 即可降低分配速率过高所造成的影响。增加年轻代空间并不会降低分配速率, 但是会减少GC的频率。如果每次GC后只有少量对象存活, minor GC 的暂停时间就不会明显增加。
     

    过早提升(Premature Promotion)

    提升速率(promotion rate), 用于衡量单位时间内从年轻代提升到老年代的数据量。一般使用 MB/sec 作为单位, 和分配速率类似。

    JVM会将长时间存活的对象从年轻代提升到老年代。根据分代假设, 可能存在一种情况, 老年代中不仅有存活时间长的对象,也可能有存活时间短的对象。这就是过早提升:对象存活时间还不够长的时候就被提升到了老年代。

    major GC 不是为频繁回收而设计的, 但 major GC 现在也要清理这些生命短暂的对象, 就会导致GC暂停时间过长。这会严重影响系统的吞吐量。

    如何测量提升速率

    可以指定JVM参数 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps , 通过GC日志来测量提升速率. JVM记录的GC暂停信息如下所示:

    0.291: [GC (Allocation Failure) 
    		[PSYoungGen: 33280K->5088K(38400K)] 
    		33280K->24360K(125952K), 0.0365286 secs] 
    	[Times: user=0.11 sys=0.02, real=0.04 secs] 
    0.446: [GC (Allocation Failure) 
    		[PSYoungGen: 38368K->5120K(71680K)] 
    		57640K->46240K(159232K), 0.0456796 secs] 
    	[Times: user=0.15 sys=0.02, real=0.04 secs] 
    0.829: [GC (Allocation Failure) 
    		[PSYoungGen: 71680K->5120K(71680K)] 
    		112800K->81912K(159232K), 0.0861795 secs] 
    	[Times: user=0.23 sys=0.03, real=0.09 secs]

    从上面的日志可以得知: GC之前和之后的 年轻代使用量以及堆内存使用量。这样就可以通过差值算出老年代的使用量。GC日志中的信息可以表述为:

    Event Time Young decreased Total decreased Promoted Promotion rate
    (事件) (耗时) (年轻代减少) (整个堆内存减少) (提升量) (提升速率)
    1st GC 291ms 28,192K 8,920K 19,272K 66.2 MB/sec
    2nd GC 446ms 33,248K 11,400K 21,848K 140.95 MB/sec
    3rd GC 829ms 66,560K 30,888K 35,672K 93.14 MB/sec
    Total 829ms     76,792K 92.63 MB/sec

    根据这些信息, 就可以计算出观测周期内的提升速率。平均提升速率为 92 MB/秒, 峰值为 140.95 MB/秒

    请注意, 只能根据 minor GC 计算提升速率。 Full GC 的日志不能用于计算提升速率, 因为 major GC 会清理掉老年代中的一部分对象。

    提升速率的意义

    和分配速率一样, 提升速率也会影响GC暂停的频率。但分配速率主要影响 minor GC, 而提升速率则影响 major GC 的频率。有大量的对象提升,自然很快将老年代填满。 老年代填充的越快, 则 major GC 事件的频率就会越高。
    此前说过, full GC 通常需要更多的时间, 因为需要处理更多的对象, 还要执行碎片整理等额外的复杂过程。

    过早提升的影响

    一般来说,过早提升的症状表现为以下形式:

    1. 短时间内频繁地执行 full GC。
    2. 每次 full GC 后老年代的使用率都很低, 在10-20%或以下。
    3. 提升速率接近于分配速率。

       

    解决方案

    简单来说, 要解决这类问题, 需要让年轻代存放得下暂存的数据。是增加年轻代的大小, 设置JVM启动参数, 类似这样: -Xmx64m -XX:NewSize=32m, 程序在执行时, Full GC 的次数自然会减少很多, 只会对 minor GC的持续时间产生影响。

    项目GC日志一直打印出Allocation Failure的日志,以其中一行为例来解读下日志信息:

    [GC (Allocation Failure) [ParNew: 367523K->1293K(410432K), 0.0023988 secs] 
    522739K->156516K(1322496K), 0.0025301 secs] [Times: user=0.04 sys=0.00, real=0.01 secs]

    GC:表明进行了一次垃圾回收,前面没有Full修饰,表明这是一次Minor GC ,注意它不表示只GC新生代,并且现有的不管是新生代还是老年代都会STW(stop-the-word)。

    Allocation Failure:表明本次引起GC的原因是因为在年轻代中没有足够的空间能够存储新的数据了。

    ParNew:表明本次GC发生在年轻代并且使用的是ParNew垃圾收集器。ParNew是一个Serial收集器的多线程版本,会使用多个CPU和线程完成垃圾收集工作(默认使用的线程数和CPU数相同,可以使用-XX:ParallelGCThreads参数限制)。该收集器采用复制算法回收内存,期间会停止其他工作线程,即Stop The World。

    367523K->1293K(410432K):单位是KB,三个参数分别为:GC前该内存区域(这里是年轻代)使用容量,GC后该内存区域使用容量,该内存区域总容量。

    0.0023988 secs: 该内存区域GC耗时,单位是秒

    522739K->156516K(1322496K):三个参数分别为:堆区垃圾回收前的大小,堆区垃圾回收后的大小,堆区总大小。

    0.0025301 secs:该内存区域GC耗时,单位是秒

    [Times: user=0.04 sys=0.00, real=0.01 secs]

    real:指的是操作从开始到结束所经过的墙钟时间(WallClock Time)
    user:指的是用户态消耗的CPU时间;
    sys:指的是内核态消耗的CPU时间。
    墙钟时间包括各种非运算的等待耗时,例如等待磁盘I/O、等待线程阻塞,而CPU时间不包括这些耗时,但当系统有多CPU或者多核的话,多线程操作会叠加这些CPU时间,所以看到user或sys时间超过real时间是完全正常的。
    user + sys 就是CPU花费的实际时间,注意这个值统计了所有CPU上的时间,如果进程工作在多线程的环境下,叠加了多线程的时间,这个值是会超出 real 所记录的值的,即 user + sys >= real 。
    多次real time时间大于usr time + sys time,表明可能有两个问题,一个是IO操作密集,另一个是cpu(分配)的额度不够。

    分析下可以得出结论:

        该次GC新生代减少了367523-1293=366239K

        Heap区总共减少了522739-156516=366223K

        366239 – 366223 =16K,说明该次共有16K内存从年轻代移到了老年代,可以看出来数量并不多,说明都是生命周期短的对象,只是这种对象有很多。

        我们需要的是尽量避免Full GC的发生,让对象尽可能的在年轻代就回收掉,所以这里可以稍微增加一点年轻代的大小,让那17K的数据也保存在年轻代中。

    解决方式:直接修改配置参数 -Xmn4g  (这里需要根据需求来设置)

    有时候,增加新生代堆内存并不能解决办法。
    当minor GC 的频率太高了,这说明创建了大量的对象。另外, 如果年轻代在 GC 之后的使用量又很低, 也没有 full GC 发生。 这表明, GC对吞吐量造成了严重的影响。
    可以通过分配分析其找出大部分垃圾产生的位置,对代码处理对象进行优化。
    刚巧今天遇到一个线上bug:
    今天项目一直在报full GC,是结算时,内存存入了大量的trade数据,现在新建一个settlementTrade对象,只存必要的字段,然后然后将--xx:xmx 和--xx:xms 从10G调整为16G,新生代xmn不变,他准备上线,我等下瞄瞄他优化后的结果,循环full gc,每次都得stw, 严重影响了吞吐量.
    系统内存存入的数据量变少, 内存也扩大。

    展开全文
  • Custom memory allocation

    2020-12-01 16:29:14
    <div><p>I think I finally cracked the nut on custom memory allocation. Back in the ~0.3 versions, libcork had custom memory allocation, but it was very invasive: you had to pass around lots of <code>...
  • Latent Dirichlet Allocation.pdf
  • QoE and Energy Aware Resource Allocation in Small Cell Networks with Power Selection, Load Management and Channel Allocation
  • allocation_pools argument in favor of allocation_pool. <p>allocation_pool is a singular word which makes more sense to use declaratively. <p>In addition, allocation_pools was originally a TypeList, ...
  • Memory Allocation Error

    2020-12-09 03:45:06
    ve seen it referenced on <a href="https://stackoverflow.com/questions/43641122/odbc-teradata-driver-hy001-memory-allocation-error-what-is-the-meaning">Stack Overflow</a> and on the ...
  • Allocation Unit Size

    2021-01-09 10:03:42
    #define DOKAN_ALLOCATION_UNIT_SIZE 512 </code></pre> <p>in public.h to 4096, and after I compiled and installed the dokan driver, the allocation size is still 512. <p>I tested it by creating a new ...
  • Support Asset Allocation

    2020-11-22 22:37:22
    <div><p>I would love for fava to have some kind of support for Asset Allocation with some graphics (i.e. sunburst). A few days ago I asked over on ...
  • Applied allocation test

    2021-01-09 06:50:18
    <div><p>Applied allocation test proposed by . </p><p>该提问来源于开源项目:googleforgames/agones</p></div>
  • allocation tracker

    2016-12-15 14:56:13
    Allocation Tracker(AS)工具比Allocation Tracker(Eclipse)工具强大的地方是更炫酷,更清晰,但是能做的事情都是一样的。 Allocation Tracker启动 在内存图中点击途中标红的部分,启动追踪,再次点击就是停止...

    Speed up your app

    Android Studio版的特点

    Allocation Tracker(AS)工具比Allocation Tracker(Eclipse)工具强大的地方是更炫酷,更清晰,但是能做的事情都是一样的。

    Allocation Tracker启动

    在内存图中点击途中标红的部分,启动追踪,再次点击就是停止追踪,随后自动生成一个alloc结尾的文件,这个文件就记录了这次追踪到的所有数据,然后会在右上角打开一个数据面板: 

    面板左上角是所有历史数据文件列表,后面是详细信息,好,现在我们来看详细介绍信息面板: 

    下面我们用字母来分段介绍

    A:查看方式选项

    A标识的是一个选择框,有2个选项 

    • Group by Method:用方法来分类我们的内存分配
    • Group by Allocator:用内存分配器来分类我们的内存分配 
      不同的选项,在D区显示的信息会不同,默认会以Group by Method来组织,我们来看看详细信息:

    从上图可以看出,首先以线程对象分类,默认以分配顺序来排序,当然你可以更改,只需在Size上点击一下就会倒序,如果以Count排序也是一样,Size就是内存大小,Count就是分配了多少次内存,点击一下线程就会查看每个线程里所有分配内存的方法,并且可以一步一步迭代到最底部: 
     

    当你以Group by Allocator来查看内存分配的情况时,详细信息区域就会变成如下: 

    默认还是以内存分配顺序来排序,但是是以每个分配者第一次分配内存的顺序: 
     
    这种方式显示的好处,是我们很好的定位我们自己的代码的分析信息,比如上图中,以包名来找到我们的程序,在这次追踪中包民根目录一共有五个类作为分配器分配了78-4-1=73次内存。

    B:Jump To Source按钮

    如果我们想看内存分配的实际在源码中发生的地方,可以选择需要跳转的对象,点击该按钮就能发现我们的源码,但是前提是你有源码:

     
    如果你能跳转到源码,Jump To Source按钮才是可用的,都是跳转到类。

    C:统计图标按钮

    该按钮比较酷炫,如果点击该按钮,会弹出一个新窗口,里面是一个酷炫的统计图标,有柱状图和轮胎图两种图形可供选择,默认是轮胎图,其中分配比例可以选择分配次数和占用内存大小,默认是大小Size

    轮胎图

     
    轮胎图是以圆心为起点,最外层是其内存实际分配的对象,每一个同心圆可能被分割成多个部分,代表了其不同的子孙,每一个同心圆代表他的一个后代,每个分割的部分代表了某一带人有多人,你双击某个同心圆中某个分割的部分,会变成以你点击的那一代为圆心再向外展开。如果想回到原始状态,双击圆心就可以了。

    1.起点

     
    圆心是我们的起点处,如果你把鼠标放到我图中标注的区域,会在右边显示当前指示的是什么线程(Thread1)以及具体信息(分配了8821次,分配了564.18k的内存),但是红框标注的区域并不代表Thread1,而是第一个同心圆中占比最大的那个线程,所以我们现在把鼠标放到第一个同心圆上,可以看出来,我们划过同心圆的轨迹时可以看到右边的树枝变化了好几个值: 
     
    2.查看某一个扇面 
    我们刚打开是全局信息,我们如果想看其中某个线程,详细信息,可以顺着某个扇面向外围滑动,当然如果你觉得不还是不清晰,可以双击该扇面全面展现该扇面的信息:

    在某个地方双击时,新的轮胎图是以双击点为圆心,你如果想到刚才的圆,双击圆心空白处就可以: 
     
    3.一个内存的完整路径 
     

    柱状图:

     
    柱状图以左边为起始点,从左到右的顺序是某个的堆栈信息顺序,纵坐标上的宽度是以其Count/Size的大小决定的。柱状图的内容其实和轮胎图没什么特别的地方

    1.起点

     
    2.查看某一个分支

     
    3.Count/Size切换

    展开全文
  • </li><li>unneeded or redundant use of g_malloc0() and memset() functions, either because they were used together, or the allocated memory is for a struct that has all members set after the allocation,...
  • <div><p>Remove the call to sync the gameserver cache during each allocation request and replaced it with using local (ready gameservers) cache. </p><p>该提问来源于开源项目:googleforgames/agones...
  • memory allocation cleanups

    2020-12-27 08:27:28
    <div><p>Spotted some issues in libmaxminddb. These ones can be grouped into category "memory allocation".</p><p>该提问来源于开源项目:maxmind/libmaxminddb</p></div>
  • Allocation enable/disable

    2021-01-07 07:44:38
    <div><p>Using Cluster Settings cluster.routing.allocation.enable to enable/disable shard allocation. This is needed to automate node/cluster/rolling restarts <p>This could handle shard allocation ...
  • Reduce memory allocation

    2020-12-09 05:52:10
    <div><p>Use benchmarking as basis and try to eliminate allocation as much as possible</p><p>该提问来源于开源项目:Http-Multipart-Data-Parser/Http-Multipart-Data-Parser</p></div>
  • packet allocation pool

    2021-01-07 18:00:07
    <div><ul><li>no more direct malloc/free with cast</li><li>reuse allocated memory for 3 common allocation case (with limit)</li></ul>该提问来源于开源项目:arvidn/libtorrent</p></div>
  • Allocation testing code

    2020-11-30 23:54:06
    <div><p>Few weeks ago I played with google allocation instrumenter. As this is ready code I allow myself to open PR to at least compare results with #245 </p><p>该提问来源于开源项目:Roaring...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 18,059
精华内容 7,223
关键字:

allocation