深度剖析（深度剖析自身存在的问题和不足）

2023-03-23 14:22:25 分类：java 阅读()

　　本篇文章为你整理了深度剖析（深度剖析自身存在的问题和不足）的详细内容，包含有深度剖析的同义词 深度剖析自身存在的问题和不足 深度剖析硅谷银行的发展历程 深度剖析美乐家 深度剖析，希望能帮助你了解 深度剖析。

　　 相信大多数人的理解是Major GC只针对老年代，Full GC会先触发一次Minor GC，不知对否？我参考了R大的分析和介绍，总结了一下相关的说明和分析结论。

　　
【易错问题】Major GC和Full GC的区别是什么？触发条件呢？

　　相信大多数人的理解是Major GC只针对老年代，Full GC会先触发一次Minor GC，不知对否？我参考了R大的分析和介绍，总结了一下相关的说明和分析结论。

　　在基于HotSpotVM的基础角度

　　针对HotSpot VM的实现，它里面的GC其实准确分类只有两大种：

　　Partial GC（部分回收模式）

　　Partial GC代表着并不收集整个GC堆的模式

　　
Young Generation GC（新生代回收模式）：它主要是进行回收新生代范围内的内存对象的GC回收器。

　　Old/Tenured Generation GC（老年代回收模式）：它主要是针对于回收老年代Old/Tenured Generation范围内的GC垃圾回收器（CMS的Concurrent Collection是这个模式）。

　　Mixed Generation GC（混合代回收模式）：收集整个young gen以及部分old gen的GC。只有G1有这个模式

　　Full GC（全体回收模式）

　　Full GC代表着收集整个JVM的运行时堆+方法区+直接堆外内存的总体范围内。（甚至可以理解为JVM进程范围内的绝大部分范围的数据区域）。

　　它会涵盖了所有的模式和区域包含：Young Gen（新生代）、Tenured Gen（老生代）、Perm/Meta Gen（元空间）（JDK8前后的版本）等全局范围的GC垃圾回收模式。

　　在一般情况下Major GC通常是跟Full GC是等价的，收集整个GC堆。但如果从HotSpot VM底层的细节出发，如果再有人说“Major GC”的时候一定要问清楚他想要指的是上面的Full GC还是Old/Tenured GC。

　　基于最简单的分代式GC策略

　　触发条件是：Young GC

　　按HotSpot VM的Serial GC的实现来看，当Young gen中的Eden区分达到阈值（属于一定的百分比进行控制）的时候触发。

　　注意：Young GC中有部分存活对象会晋升到Old/Tenured Gen，所以Young GC后Old Gen的占用量通常会有所升高。

　　触发条件是：Full GC

　　
当准备要触发一次Young GC时，如果发现统计数据说之前Young Old/Tenured Gen剩余的空间大，则不会触发Young GC，而是转为触发Full GC（因为HotSpot VM的GC里，除了CMS的Concurrent collection之外，其它能收集Old/Tenured Gen的GC都会同时收集整个GC堆，包括Young gen，所以不需要事先触发一次单独的Young GC）；

　　
如果有Perm/Meta gen的话，要在Perm/Meta gen分配空间但已经没有足够空间时，也要触发一次full GC。

　　
System.gc()方法或者Heap Dump自带的GC，默认也是触发Full GC。HotSpot VM里其它非并发GC的触发条件复杂一些，不过大致的原理与上面说的其实一样。

　　
注意：Parallel Scavenge（-XX:+UseParallelGC）框架下，默认是在要触发Full GC前先执行一次Young GC，并且两次GC之间能让应用程序稍微运行一小下，以期降低Full GC的暂停时间（因为young GC会尽量清理了Young Gen的垃圾对象，减少了Full GC的扫描工作量）。控制这个行为的VM参数是-XX:+ScavengeBeforeFullGC。

　　触发条件是：Concurrent GC

　　Concurrent GC的触发条件就不太一样。以CMS GC为例，它主要是定时去检查Old Gen的使用量，当使用量超过了触发比例就会启动一次CMS GC，对Old gen做并发收集。

　　GC回收器对应的GC模式列举

　　在Hotspot JVM实现的Serial GC, Parallel GC, CMS, G1 GC中大致可以对应到某个Young GC和Old GC算法组合；

　　
Serial GC算法：Serial Young GC ＋ Serial Old GC （实际上它是全局范围的Full GC）；

　　Parallel GC算法：Parallel Young GC ＋ 非并行的PS MarkSweep GC / 并行的Parallel Old GC（这俩实际上也是全局范围的Full GC），选PS MarkSweep GC 还是 Parallel Old GC 由参数UseParallelOldGC来控制；

　　CMS算法：ParNew（Young）GC + CMS（Old）GC （piggyback on ParNew的结果／老生代存活下来的object只做记录，不做compaction）＋ Full GC for CMS算法（应对核心的CMS GC某些时候的不赶趟，开销很大）；

　　G1 GC：Young GC + mixed GC（新生代，再加上部分老生代）＋ Full GC for G1 GC算法（应对G1 GC算法某些时候的不赶趟，开销很大）；

　　GC回收模式的触发总结

　　搞清楚了上面这些组合，我们再来看看各类GC算法的触发条件。简单说，触发条件就是某GC算法对应区域满了，或是预测快满了。比如，

　　各种Young GC的触发原因都是eden区满了；

　　Serial Old GC／PS MarkSweep GC／Parallel Old GC的触发则是在要执行Young GC时候预测其promote的object的总size超过老生代剩余size；

　　CMS GC的initial marking的触发条件是老生代使用比率超过某值；

　　G1 GC的initial marking的触发条件是Heap使用比率超过某值；

　　Full GC for CMS算法和Full GC for G1 GC算法的触发原因很明显，就是4.3 和 4.4 的fancy算法不赶趟了，只能全局范围大搞一次GC了（相信我，这很慢！这很慢！这很慢！）；

　　
很多人都见过JVM调优建议里使用这个参数，对吧？但是为什么要用它，什么时候应该用而什么时候用了会掉坑里呢？

　　
首先，要了解的是这个参数的作用。在Oracle/Sun JDK这个具体实现上，System.gc()的默认效果是引发一次stop-the-world的Full GC，由上面所知就是针对于整个GC堆做内存垃圾收集。

　　
再次，如果采用了用了-XX:+DisableExplicitGC参数后，System.gc()的调用就会变成一个空调用，完全不会触发任何GC（但是“函数调用”本身的开销还是存在的哦～）。

　　为啥要用这个参数呢？最主要的原因是为了防止某些小白同学在代码里到处写System.gc()的调用而干扰了程序的正常运行吧。

　　有些应用程序本来可能正常跑一天也不会出一次Full GC，但就是因为有人在代码里调用了System.gc()而不得不间歇性被暂停。

　　有些时候这些调用是在某些库或框架里写的，改不了它们的代码但又不想被这些调用干扰也会用这参数。

　　
-XX:+DisableExplicitGC看起来这参数应该总是开着嘛。有啥坑呢？

　　下述三个条件同时满足时会发生的

　　应用本身在GC堆内的对象行为良好，正常情况下很久都不发生Full GC。

　　应用大量使用了NIO的direct memory，经常、反复的申请DirectByteBuffer。

　　使用了-XX:+DisableExplicitGC。

　　能观察到的现象是：

　　

java.lang.OutOfMemoryError: Direct buffer memory

 

　　 at java.nio.Bits.reserveMemory(Bits.java:633)

　　 at java.nio.DirectByteBuffer. init (DirectByteBuffer.java:98)

　　 at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:288)

　　

 

　　用一个案例来分析这现象：

　　

import java.nio.*;

 

　　public class DisableExplicitGCDemo {

　　 public static void main(String[] args) {

　　 for (int i = 0; i 100000; i++) {

　　 ByteBuffer.allocateDirect(128);

　　 System.out.println("Done");

　　

 

　　然后编译、运行。

　　

$ java -version

 

　　java version "1.6.0_25"

　　Java(TM) SE Runtime Environment (build 1.6.0_25-b06)

　　Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)

　　$ javac DisableExplicitGCDemo.java

　　$ java -XX:MaxDirectMemorySize=10m -XX:+PrintGC -XX:+DisableExplicitGC DisableExplicitGCDemo

　　Exception in thread "main" java.lang.OutOfMemoryError: Direct buffer memory

　　 at java.nio.Bits.reserveMemory(Bits.java:633)

　　 at java.nio.DirectByteBuffer. init (DirectByteBuffer.java:98)

　　 at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:288)

　　 at DisableExplicitGCDemo.main(DisableExplicitGCDemo.java:6)

　　$ java -XX:MaxDirectMemorySize=10m -XX:+PrintGC DisableExplicitGCDemo

　　[GC 10996K- 10480K(120704K), 0.0433980 secs]

　　[Full GC 10480K- 10415K(120704K), 0.0359420 secs]

　　Done

　　

 

　　
可以看到，同样的程序，不带-XX:+DisableExplicitGC时能正常完成运行，而带上这个参数后却出现了OOM。-XX:MaxDirectMemorySize=10m限制了DirectByteBuffer能分配的空间的限额，以便问题更容易展现出来。不用这个参数就得多跑一会儿了。

　　
循环不断申请DirectByteBuffer但并没有引用，所以这些DirectByteBuffer应该刚创建出来就已经满足被GC的条件，等下次GC运行的时候就应该可以被回收。

　　
实际上却没这么简单。DirectByteBuffer是种典型的“冰山”对象，也就是说它的Java对象虽然很小很无辜，但它背后却会关联着一定量的native memory资源，而这些资源并不在GC的控制之下，需要自己注意控制好。

　　
对JVM如何使用native memory不熟悉的同学可以研究一下这篇演讲，“Where Does All the Native Memory Go”。

　　【盲点问题】DirectByteBuffer的回收问题

　　Oracle/Sun JDK的实现里，DirectByteBuffer有几处值得注意的地方。

　　DirectByteBuffer没有finalizer，它的native memory的清理工作是通过sun.misc.Cleaner自动完成的。

　　sun.misc.Cleaner是一种基于PhantomReference的清理工具，比普通的finalizer轻量些。

　　
"A cleaner tracks a referent object and encapsulates a thunk of arbitrary cleanup code. Some time after the GC detects that a cleaners referent has become phantom-reachable, the reference-handler thread will run the cleaner."

　　

/**

 

　　 * General-purpose phantom-reference-based cleaners.

　　 * p Cleaners are a lightweight and more robust alternative to finalization.

　　 * They are lightweight because they are not created by the VM and thus do not

　　 * require a JNI upcall to be created, and because their cleanup code is

　　 * invoked directly by the reference-handler thread rather than by the

　　 * finalizer thread. They are more robust because they use phantom references,

　　 * the weakest type of reference object, thereby avoiding the nasty ordering

　　 * problems inherent to finalization.

　　 * p A cleaner tracks a referent object and encapsulates a thunk of arbitrary

　　 * cleanup code. Some time after the GC detects that a cleaners referent has

　　 * become phantom-reachable, the reference-handler thread will run the cleaner.

　　 * Cleaners may also be invoked directly; they are thread safe and ensure that

　　 * they run their thunks at most once.

　　 * p Cleaners are not a replacement for finalization. They should be used

　　 * only when the cleanup code is extremely simple and straightforward.

　　 * Nontrivial cleaners are inadvisable since they risk blocking the

　　 * reference-handler thread and delaying further cleanup and finalization.

　　 * @author Mark Reinhold

　　 * @version %I%, %E%

　　

 

　　Oracle/Sun JDK中的HotSpot VM只会在Old Gen GC（Full GC/Major GC或者Concurrent GC都算）的时候才会对Old Gen中的对象做Reference Processing，而在Young GC/Minor GC时只会对Young Gen里的对象做Reference processing。Full GC会对Old Gen做Reference processing，进而能触发Cleaner对已死的DirectByteBuffer对象做清理工作。

　　
如果很长一段时间里没做过GC或者只做了Young GC的话则不会在Old Gen触发Cleaner的工作，那么就可能让本来已经死了的、但已经晋升到Old Gen的DirectByteBuffer关联的Native Memory得不到及时释放。

　　
为DirectByteBuffer分配空间过程中会显式调用System.gc()，以通过Full GC来强迫已经无用的DirectByteBuffer对象释放掉它们关联的native memory。

　　


// These methods should be called whenever direct memory is allocated or

 

　　// freed. They allow the user to control the amount of direct memory

　　// which a process may access. All sizes are specified in bytes.

　　static void reserveMemory(long size) {

　　 synchronized (Bits.class) {

　　 if (!memoryLimitSet VM.isBooted()) {

　　 maxMemory = VM.maxDirectMemory();

　　 memoryLimitSet = true;

　　 if (size = maxMemory - reservedMemory) {

　　 reservedMemory += size;

　　 return;

　　 System.gc();

　　 try {

　　 Thread.sleep(100);

　　 } catch (InterruptedException x) {

　　 // Restore interrupt status

　　 Thread.currentThread().interrupt();

　　 synchronized (Bits.class) {

　　 if (reservedMemory + size maxMemory)

　　 throw new OutOfMemoryError("Direct buffer memory");

　　 reservedMemory += size;

　　

 

　　这几个实现特征使得Oracle/Sun JDK依赖于System.gc()触发GC来保证DirectByteMemory的清理工作能及时完成。

　　如果打开了-XX:+DisableExplicitGC，清理工作就可能得不到及时完成，于是就有机会见到direct memory的OOM，也就是上面的例子演示的情况。我们这边在实际生产环境中确实遇到过这样的问题。

　　如果你在使用Oracle/Sun JDK，应用里有任何地方用了direct memory，那么使用-XX:+DisableExplicitGC要小心。如果用了该参数而且遇到direct memory的OOM，可以尝试去掉该参数看是否能避开这种OOM。如果担心System.gc()调用造成Full GC频繁，可以尝试下面提到 -XX:+ExplicitGCInvokesConcurrent 参数

　　以上就是深度剖析（深度剖析自身存在的问题和不足）的详细内容，想要了解更多 深度剖析的内容，请持续关注盛行IT软件开发工作室。

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。

标签： java

相关文章阅读

  • java Springboot集成mybatis-plus的方法是什么
  • 浅谈几种Java自定义异常处理方式
  • Java Map所有的值转为String类型
  • java代码中格式化金额 java格式化小数
  • java计算器源代码资源 java计算器简单代码
  • 【java】（一）SpringBoot 源码解析——SpringApplication 初始化（）
  • Spring学习笔记（spring教程 csdn）
  • HDFS Architecture Guide（）
  • 哈工大软件构造Lab3（2022）（哈工大软件构造lab3）
  • nginx基础（nginx基础教程）
  • Java 中HashMap详解(含HashTable, ConcurrentHashMap)（java hashmap使用方法）
  • Java 线程池之Jetty 线程池学习总结（java线程池的使用方法）
  • java线程基础（java 线程教程）
  • 聊聊 Netty 那些事儿之 Reactor 在 Netty 中的实现(创建篇)（）
  • nginx（nginx负载均衡）
    • 留言与评论（共有 条评论）
       
    验证码：