JVM之GC垃圾回收全面解析(一)

GC资料很多,有点乱,整理了一篇通俗而全面的的文档。看完包会。

比较全面要了解GC回收,首先得了解几个概念:

一. 多进程,多线程,并发,并行

 1. 多进程,同时打开word,excel,ppt

 2. 多进程,迅雷同时下载多个资源

 3. 并发Concurrency,一个cpu在多个线程之间复用。所有并发处理都会经历排 队等候,唤醒,执行等步骤。微观上排队, 宏观上同时!

 4. 并行Parallelism,多个线程同时发生并处理(多核),没有竞争,等待

 5. 多线程可能被分配到一个CPU内核中执行,也可能被分配到不同CPU执行, 分配过程是操作系统所为,不可人为控制

二. GC动作:

 1. Minor[maɪnə] GC:新生代GC,短暂stop-the-world

 2. Major[meɪdʒə]GC==Full GC: 老年代GC

 3. Full GC不会先进行Minor GC,可优化比如CMS,设置CMSScavengeBeforeRemark 优化,CMS remark之前先进行一次 Minor GC

三. GC名词:

吞吐量 = 运行用户代码时间 /(运行用户代码时间 + 垃圾收集时间)

响应时间:停顿时间越短就越适合需要与用户交互的程序,良好的响应速度能提升用户体验。

高吞吐量:而高吞吐量则可以高效率地利用CPU时间,尽快完成程序的运算任务,主要适  合在后台运算不需要太多交互的任务

理解了上面概念后,可以看下GC的算法

 1. 标记清理mark-sweep:标记-清除-----缺陷:产生内存碎片

 2. 标记整理compaction :标记-整理(stack_scan):将存活对象压缩到内存一端,再清理边界外空间,解决碎片问题------缺陷:适用于对象较多的场合如老年代

 3. 复制:内存空间分对称2块,清理时复制存活对象到未使用块中,再清理该块空间,无碎片------缺陷:内存浪费,适用于对象少,小且早死的场合如新生代

 4. 分代思想:依据对象的存活周期进行分类,短命对象归为新生代,长命对象归 为老年代。根据不同代的特点,选取合适的收集算法(特别大对象直接去老年代)

目前GC几种堆结构(全面)

GC Heap结构:

 Parallel  1.7,1.8默认并行收集器    注重系统的吞吐量

 新生代3         总大小    已用    初始值        当前值       最大值

  PSYoungGen     total 4608K, used 3718K [0x0000000ff980000, 0x00000000ffe80000, 0x00000001000000)

  伊甸区eden space  中小对象出生的地方

 eden space 4096K, 78% used [0x00000000ff980000,0x00000000ffca7978,0x00000000ffd80000)

 幸存区survivor space复制算法多次回收不掉则去ParOldGen 幸存代占新生代1/10

     from space 512K, 95% used [0x00000000ffe00000,0x00000000ffe7a020,0x00000000ffe80000)

    to   space 512K, 0% used [0x00000000ffd80000,0x00000000ffd80000,0x00000000ffe00000)

 老年代5        

 ParOldGen     total 4096K, used 666K [0x00000000fec00000, 0x00000000ff000000, 0x00000000ff980000)

 老年区 大对象和多次未回收的对象,先整理再清除

    object space 4096K, 16% used [0x00000000fec00000,0x00000000feca6af0,0x00000000ff000000)

元空间(原永久区)

 Metaspace       used 3164K, capacity 4494K, committed 4864K, reserved 1056768K

 类静态信息         容量      提交        预留

    class space    used 336K, capacity 386K, committed 512K, reserved 1048576K

 

 CMS版   并发收集器  注重解决停顿时间

  par new generation total 1856K, used 293K [0x00000000fec00000, 0x00000000fee00000, 0x00000000ff2a0000)

   eden space 1664K,  11% used [0x00000000fec00000, 0x00000000fec2ed38, 0x00000000feda0000)

   from space 192K,   55% used [0x00000000fedd0000, 0x00000000fedea830, 0x00000000fee00000)

   to   space 192K,   0% used [0x00000000feda0000, 0x00000000feda0000, 0x00000000fedd0000)

 concurrent mark-sweep generation total 4096K, used 1021K [0x00000000, 0x000000, 0x000000000)

  Metaspace     used 3277K, capacity 4494K, committed 4864K, reserved 1056768K

   class space    used 349K, capacity 386K, committed 512K, reserved 1048576K

 

G1版  CMS升级版  注重解决停顿时间同时兼顾吞吐量

  garbage-first heap   total 6144K, used 0K [0x00000000fec00000, 0x00000000ff200000, 0x0000000100000000)

   region size 1024K, 1 young (1024K), 0 survivors (0K)

  元空间(原永久区)

 Metaspace       used 2247K, capacity 4480K, committed 4480K, reserved 1056768K

   class space    used 243K, capacity 384K, committed 384K, reserved 1048576K

不同版本的heap结构不一样,注意区分。下篇帖子会详细介绍各个收集器和GC优化




 

你可能感兴趣的:(深入JVM)