深入理解java虚拟机

深入理解java虚拟机

（一）虚拟机内存划分

Java虚拟机在执行Java程序时，会把它管理的内存划分为若干个不同的数据区。这些区域有不同的特性，起不同的作用。它们有各自的创建时间，销毁时间。有的区域随着进程的启动而创建，随着进程结束而销毁，有的则始终贯穿虚拟机整个生命周期。

Java虚拟机运行时内存区域主要分为七部分，分别是：程序计数器，Java虚拟机栈，本地方法栈，方法区，Java堆，运行时常量池，直接内存。

如上图所示（图片来源于网络）：

蓝色区域包裹的部分为运行时几个数据区域：

白色的部分为线程私有的，既随着线程的启动而创建。每个线程都拥有各自的一份内存区域。它们是：JAVA栈（JAVA STACK），本地方法栈(NATIVE METHOD STACK),和程序计数器（PROGRAM COUNTER REGISTER）。

黄色部分是线程共享的，所有的线程共享该区域的内容。他们是：

方法区（METHOD AREA），堆（HEAP）。

我们分别来介绍这些区域。

（1）程序计数器（program counter register）

学过计算机组成原理的都知道计算机处理器中的程序计数器。当处理器执行一条指令时，首先需要根据PC中存放的指令地址，将指令由内存取到指令寄存器中，此过程称为“取指令”。与此同时，PC中的地址或自动加1或由转移指针给出下一条指令的地址。此后经过分析指令，执行指令。完成第一条指令的执行，而后根据PC取出第二条指令的地址，如此循环，执行每一条指令。

处理器的程序计数器是指寄存器，而java程序计数器是指一小块内存空间。java代码编译字节码之后，虚拟机会一行一行的解释字节码，并翻印成本地代码。这个程序计数器盛放的就是当前线程所执行字节码的行号的指示器。在虚拟机概念模型中，字节码解释器工作室就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支，循环，跳转，异常处理等都依赖于它。

Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式实现的，因此为了线程切换后还能恢复执行位置，每条线程都需要一个独立的程序计数器。

如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果执行的是Java Native方法，这个计数器值为空。

而且程序计数器是Java虚拟机中没有规定任何OutOfMemoryError的区域。

（2）虚拟机栈

Java虚拟机栈（VM Stack）也是线程私有的，因此它的生命周期也和线程相同。它存放的是Java方法执行时的数据，既描述的是Java方法执行的内存模型：每个方法开始执行的时候，都会创建一个栈帧（Stack Frame）用于储存局部变量表、栈操作数、动态链接、方法出口等信息。每个方法从调用到执行完成就对应一个栈帧在虚拟机栈中入栈到出栈的过程。经常有人把Java内存分为堆内存和栈内存，这种是比较粗糙的分法，很大原因是大多数程序‘猿’最关注的，与对象内存分配最密切的区域就是堆和栈。局部变量表存放的是编译器可知的各种基本数据类型(boolean 、byte、int、long、char、short、float、double)、对象引用（reference类型）和returnAddress类型（它指向了一条字节码指令的地址）。其中64bit长度的long和double会占用两个局部变量空间(Slot)，其余的数据类型只占用一个。局部变量表所需的内存空间是在编译时期确定的，在方法运行期间不会改变局部变量表的大小。在Java虚拟机规范中，对这部分区域规定了两种异常：1、当一个线程的栈深度大于虚拟机所允许的深度的时候，将会抛出StackOverflowError异常； 2、如果当创建一个新的线程时无法申请到足够的内存，则会抛出OutOfMemeryError异常。

（3）本地方法栈

本地方法栈（Native Method Stack）与虚拟机栈所发挥的作用是十分相似的，他们之间的区别不过是虚拟机栈为Java方法字节码服务，而本地方法栈则为Native方法服务。在虚拟机规范中对本地方法使用的语言和使用方法与数据结构没有强制规定，因此具体的虚拟机可

以自由实现它。Sun HotSpot虚拟机把本地方法栈和虚拟机栈合二为一。和虚拟机栈一样，本地方法栈也会抛出OutOfMemoryError和StackOverflowError异常。

接下来我们介绍的都是所有线程共享的区域了。

（4）堆（heap）

堆是虚拟机中最大的一块内存区域了，被所有线程共享，在虚拟机启动时创建。它的目的便是存放对象实例。堆是垃圾收集器管理的主要区域，因此很多时候也被成为…GC’堆（Garbage Collected Heap）。

从垃圾回收的角度来讲，现在的收集器包括HotSpot都采用分代收集算法，所以堆又可以分为：新生代（Young）和老年代（Tenured），再细致一点，新生代又可分为Eden、From Survivor 空间和To Survivor空间。从内存分配的角度来讲，又可以分为若干个线程私有的分配缓冲区（Thread Local Allocation Buffer ,TLAB）。当堆空间不足切无法扩展，会抛出OutOfMemoryError异常。

（5）方法区（Method Area）

与Java堆一样，是各个线程共享的内存区域，用于存储被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。它有个别名叫做非堆Non-Heap。对于HotSpot 开发者来说，很多人称它为“永久代”（Permanent Generation），但是两者并不等价，仅仅是因为HotSpot虚拟机设计团队把GC分代收集扩展至方法区，或者说使用永久代来实现方法区而已，这样HotSpot的垃圾收集器可以向管理堆一样管理这部分内存。但是因为永久代有“-XX：MaxPermSize的上限，使其更容易内存溢出。因此在JDK1.7的HotSpot中，已经把原本放在永久代的字符串常量池移出去了。

当方法区无法满足内存分配需求的时候，会抛出OutOfMemoryError异常。

（6）常量池

运行时常量池（Runtime Constant Pool）是方法区的一部分。Class文件中出了类的版本、字段、方法、接口等信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译器生成的各种字面量和符号引用，这些内容将在类加载后进入方法区存放。

运行时常量池相对于Class文件常量池的另外一个重要特征是具有动态性，运行期间也可能有新的常量池放入持重，比如String.intern()方法。

运行时常量池属于方法区一部分，自然会抛出OutOfMemoryError异常。

（7）直接内存

直接内存（Direct Memory）不属于虚拟机中定义的内存区域，而是堆外内存。

JDK1.4 中新加入了NIO(new Input/Output)类，引入了一种基于通道（Channel）和缓冲区（Buffer）的I/O方式，它可以使用Native函数直接分配堆外内存，然后通过Java堆中的

DirectByteBuffer对象作为这快内存的引用进行操作。这样能在一些场景中显著提高新能性能。如果直接内存不足时，会抛出OutOfMemoryError异常。

GC在什么时候对什么做了什么？

要回答这个问题，先了解下GC的发展史、jvm运行时数据区的划分、jvm内存分配策略、jvm垃圾收集算法等知识。

先说下jvm运行时数据的划分，粗暴的分可以分为堆区(Heap)和栈区(Stack)，但jvm 的分法实际上比这复杂得多，大概分为下面几块：

1、程序计数器(Program Conuter Register)

程序计数器是一块较小的内存空间，它是当前线程执行字节码的行号指示器，字节码解释工作器就是通过改变这个计数器的值来选取下一条需要执行的指令。它是线程私有的内存，也是唯一一个没有OOM异常的区域。

2、Java虚拟机栈区(Java Virtual Machine Stacks)

也就是通常所说的栈区，它描述的是Java方法执行的内存模型，每个方法被执行的时候都创建一个栈帧(Stack Frame)，用于存储局部变量表、操作数栈、动态链接、方法出口等。每个方法被调用到完成，相当于一个栈帧在虚拟机栈中从入栈到出栈的过程。此区域也是线程私有的内存，可能抛出两种异常：如果线程请求的栈深度大于虚拟机允许的深度将抛出StackOverflowError；如果虚拟机栈可以动态的扩展，扩展到无法动态的申请到足够的内存时会抛出OOM异常。

3、本地方法栈(Native Method Stacks)

本地方法栈与虚拟机栈发挥的作用非常相似，区别就是虚拟机栈为虚拟机执行Java方法，本地方法栈则是为虚拟机使用到的Native方法服务。

4、堆区(Heap)

所有对象实例和数组都在堆区上分配，堆区是GC主要管理的区域。堆区还可以细分为新生代、老年代，新生代还分为一个Eden区和两个Survivor区。此块内存为所有线程共享区域，当堆中没有足够内存完成实例分配时会抛出OOM异常。

5、方法区(Method Area)

方法区也是所有线程共享区，用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译后的代码等数据。GC在这个区域很少出现，这个区域内存回收的目标主要是对常量池的回收和类型的卸载，回收的内存比较少，所以也有称这个区域为永久代(Permanent Generation)的。当方法区无法满足内存分配时抛出OOM异常。

6、运行时常量池(Runtime Constant Pool)

运行时常量池是方法区的一部分，用于存放编译期生成的各种字面量和符号引用。

垃圾收集(Garbage Collection)并不是Java独有的，最早是出现在Lisp语言中，它做的事就是自动管理内存，也就是下面三个问题：

1、什么时候回收

2、哪些内存需要回收

3、如何回收

1、什么时候回收？

上面说到GC经常发生的区域是堆区，堆区还可以细分为新生代、老年代，新生代还分为一个Eden区和两个Survivor区。

1.1对象优先在Eden中分配，当Eden中没有足够空间时，虚拟机将发生一次Minor GC，因为Java大多数对象都是朝生夕灭，所以Minor GC非常频繁，而且速度也很快；

1.2 Full GC，发生在老年代的GC，当老年代没有足够的空间时即发生Full GC，发生Full GC一般都会有一次Minor GC。大对象直接进入老年代，如很长的字符串数组，虚拟机提供一个-XX:PretenureSizeThreadhold参数，令大于这个参数值的对象直接在老年代中分配，避免在Eden区和两个Survivor区发生大量的内存拷贝；

1.3发生Minor GC时，虚拟机会检测之前每次晋升到老年代的平均大小是否大于老年代的剩余空间大小，如果大于，则进行一次Full GC，如果小于，则查看HandlePromotionFailure设置是否允许担保失败，如果允许，那只会进行一次Minor GC，如果不允许，则改为进行一次Full GC。

2、哪些内存需要回收

jvm对不可用的对象进行回收，哪些对象是可用的，哪些是不可用的？Java并不是采用引用计数算法来判定对象是否可用，而是采用根搜索算法(GC Root Tracing)，当一个对象到GC Roots没有任何引用相连接，用图论来说就是从GC Roots到这个对象不可达，则证明此对象是不可用的，说明此对象可以被GC。对于这些不可达对象，也不是一下子就被GC，而是至少要经历两次标记过程：如果对象在进行根搜索算法后发现没有与GC Roots

相连接的引用链，那它将会第一次标记并且进行一次筛选，筛选条件是此对象有没有必要执行finalize()方法，当对象没有覆盖finalize()方法或者finalize()方法已经被虚拟机调用执行过一次，这两种情况都被视为没有必要执行finalize()方法，对于没有必要执行finalize()方法的将会被GC，对于有必要有必要执行的，对象在finalize()方法中可能会自救，也就是重新与引用链上的任何一个对象建立关联即可。

3、如何回收

选择不同的垃圾收集器，所使用的收集算法也不同。

在新生代中，每次垃圾收集都发现有大批对象死去，只有少量存活，则使用复制算法，新生代内存被分为一个较大的Eden区和两个较小的Survivor区，每次只使用Eden区和一个Survivor区，当回收时将Eden区和Survivor还存活着的对象一次性的拷贝到另一个Survivor 区上，最后清理掉Eden区和刚才使用过的Survivor区，Eden和Survivor的默认比例是8：1，可以使用-XX:SurvivorRatio来设置该比例。

而老年代中对象存活率高，没有额外的空间对它进行分配担保，必须使用“标记-清理”或“标记-整理”算法。

内存管理与回收

1、Java虚拟机运行时的数据区

2、常用的内存区域调节参数

-Xms：初始堆大小，默认为物理内存的1/64(<1GB)；默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制

-Xmx：最大堆大小，默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制

-Xmn：新生代的内存空间大小，注意：此处的大小是（eden+ 2 survivor space)。与jmap -heap中显示的New gen是不同的。整个堆大小=新生代大小+ 老生代大小+ 永久代大小。

在保证堆大小不变的情况下，增大新生代后,将会减小老生代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。

-XX:SurvivorRatio：新生代中Eden区域与Survivor区域的容量比值，默认值为8。两个Survivor区与一个Eden区的比值为2:8,一个Survivor区占整个年轻代的1/10。-Xss：每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K。应根据应用的线程所需内存大小进行适当调整。在相同物理内存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，

经验值在3000~5000左右。一般小的应用，如果栈不是很深，应该是128k够用的，大的应用建议使用256k。这个选项对性能影响比较大，需要严格的测试。和threadstacksize 选项解释很类似,官方文档似乎没有解释,在论坛中有这样一句话:"-Xss is translated in a VM flag named ThreadStackSize‖一般设置这个值就可以了。

-XX:PermSize：设置永久代(perm gen)初始值。默认值为物理内存的1/64。

-XX:MaxPermSize：设置持久代最大值。物理内存的1/4。

3、内存分配方法

1）堆上分配2）栈上分配3）堆外分配（DirectByteBuffer或直接使用Unsafe.allocateMemory,但不推荐这种方式）

4、监控方法

1）系统程序运行时可通过jstat –gcutil来查看堆中各个内存区域的变化以及GC的工作状态；

2）启动时可添加-XX:+PrintGCDetails –Xloggc:输出到日志文件来查看GC的状况；

3）jmap –heap可用于查看各个内存空间的大小；

5）断代法可用GC汇总

一、新生代可用GC

1）串行GC(Serial Copying)：client模式下默认GC方式，也可通过-XX:+UseSerialGC 来强制指定；默认情况下eden、s0、s1的大小通过-XX:SurvivorRatio来控制，默认为8，含义

为eden:s0的比例，启动后可通过jmap –heap [pid]来查看。

默认情况下，仅在TLAB或eden上分配，只有两种情况下会在老生代分配：

1、需要分配的内存大小超过eden space大小；

2、在配置了PretenureSizeThreshold的情况下，对象大小大于此值。

默认情况下，触发Minor GC时：

之前Minor GC晋级到old的平均大小<老生代的剩余空间

默认情况下，新生代对象晋升到老生代的规则：

1、经历多次minor gc仍存活的对象，可通过以下参数来控制：以MaxTenuringThreshold值为准，默认为15。

2、to space放不下的，直接放入老生代；

2）并行GC（ParNew）：CMS GC时默认采用，也可采用-XX:+UseParNewGC强制指定；垃圾回收的时候采用多线程的方式。

3）并行回收GC(Parallel Scavenge)：server模式下默认的GC方式，也可采用-XX:+UseParallelGC强制指定；eden、s0、s1的大小可通过-XX:SurvivorRatio来控制，但默认情况下

以-XX:InitialSurivivorRatio为准，此值默认为8，代表的为新生代大小: s0，这点要特别注意。

默认情况下，当TLAB、eden上分配都失败时，判断需要分配的内存大小是否>= eden space的一半大小，如是就直接在老生代上分配；

默认情况下的垃圾回收规则：

1、在回收前PS GC会先检测之前每次PS GC时，晋升到老生代的平均大小是否大于老生代的剩余空间，如大于则直接触发full GC；

2、在回收后，也会按照上面的规则进行检测。

默认情况下的新生代对象晋升到老生代的规则：

1、经历多次minor gc仍存活的对象，可通过以下参数来控制：AlwaysTenure，默认false，表示只要minor GC时存活，就晋升到老生代；NeverTenure，默认false，表示永不晋升到老生代；上面两个都没设置的情冴下，如UseAdaptiveSizePolicy，启动时以InitialTenuringThreshold值作为存活次数的阈值，在每次psgc后会动态调整，如不使用UseAdaptiveSizePolicy，则以MaxTenuringThreshold为准。

2、to space放不下的，直接放入老生代。

在回收后，如UseAdaptiveSizePolicy，PS GC会根据运行状态动态调整eden、to 以及TenuringThreshold的大小。如果不希望动态调整可设置-XX:-UseAdaptiveSizePolicy。如希望跟踪每次的变化情况，可在启劢参数上增加：PrintAdaptiveSizePolicy。

二、老生代可用GC

1、串行GC(Serial Copying)：client方式下默认GC方式，可通过-XX:+UseSerialGC 强制指定。

触发机制汇总：

1）old gen空间不足；

2）perm gen空间不足；

3）minor gc时的悲观策略；

4）minor GC后在eden上分配内存仍然失败；

5）执行heap dump时；

6）外部调用System.gc，可通过-XX:+DisableExplicitGC来禁止。

2、并行回收GC(Parallel Scavenge)：server模式下默认GC方式，可通过-XX:+UseParallelGC强制指定；并行的线程数为当cpu core<=8 ? cpu core : 3+(cpu core*5)/8或通过-XX:ParallelGCThreads=x来强制指定。如ScavengeBeforeFullGC 为true（默认值），则先执行minor GC。

3、并行Compacting：可通过-XX:+UseParallelOldGC强制指定。

4、并发CMS：可通过-XX:+UseConcMarkSweepGC来强制指定。并发的线程数默认为:( 并行GC线程数+3)/4，也可通过ParallelCMSThreads指定。

触发机制：

1、当老生代空间的使用到达一定比率时触发；

Hotspot V 1.6中默认为65%，可通过PrintCMSInitiationStatistics（此参数在V 1.5中不能用）来查看这个值到底是多少；可通过CMSInitiatingOccupancyFraction来强制指定，默认值并不是赋值在了这个值上，是根据如下公式计算出来的：((100 - MinHeapFreeRatio) +(double)(CMSTriggerRatio * MinHeapFreeRatio) / 100.0)/ 100.0; 其中,MinHeapFreeRatio默认值：40 CMSTriggerRatio默认值：80。

2、当perm gen采用CMS收集且空间使用到一定比率时触发；

perm gen采用CMS收集需设置：-XX:+CMSClassUnloadingEnabled Hotspot V 1.6中默认为65%；可通过CMSInitiatingPermOccupancyFraction来强制指定，同样，它是根据如下公式计算出来的：((100 - MinHeapFreeRatio) +(double)(CMSTriggerPermRatio* MinHeapFreeRatio) / 100.0)/ 100.0; 其中，MinHeapFreeRatio默认值：40 CMSTriggerPermRatio默认值：80。

3、Hotspot根据成本计算决定是否需要执行CMS GC；可通过-XX:+UseCMSInitiatingOccupancyOnly来去掉这个动态执行的策略。

4、外部调用了System.gc，且设置了ExplicitGCInvokesConcurrent；需要注意，在hotspot 6中，在这种情况下如应用同时使用了NIO，可能会出现bug。

6、GC组合

1）默认GC组合

2）可选的GC组合

7、GC监测

1）jstat –gcutil [pid] [intervel] [count]

2）-verbose:gc // 可以辅助输出一些详细的GC信息；-XX:+PrintGCDetails // 输出GC详细信息；-XX:+PrintGCApplicationStoppedTime // 输出GC造成应用暂停的时间

-XX:+PrintGCDateStamps // GC发生的时间信息；-XX:+PrintHeapAtGC // 在GC 前后输出堆中各个区域的大小；-Xloggc:[file] // 将GC信息输出到单独的文件中，建议都加上，这个消耗不大，而且对查问题和调优有很大的帮助。gc的日志拿下来后可使用GCLogViewer或gchisto进行分析。

3）图形化的情况下可直接用jvisualvm进行分析。

4）查看内存的消耗状况

（1）长期消耗，可以直接dump，然后MAT(内存分析工具)查看即可

（2）短期消耗，图形界面情况下，可使用jvisualvm的memory profiler或jprofiler。

8、系统调优方法

步骤：1、评估现状2、设定目标3、尝试调优4、衡量调优5、细微调整

设定目标：

1）降低Full GC的执行频率？

2）降低Full GC的消耗时间？

3）降低Full GC所造成的应用停顿时间？

4）降低Minor GC执行频率？

5）降低Minor GC消耗时间？

例如某系统的GC调优目标：降低Full GC执行频率的同时，尽可能降低minor GC的执行频率、消耗时间以及GC对应用造成的停顿时间。

衡量调优：

1、衡量工具

1）打印GC日志信息：-XX:+PrintGCDetails –XX:+PrintGCApplicationStoppedTime -Xloggc: {文件名} -XX:+PrintGCTimeStamps

2）jmap：（由于每个版本jvm的默认值可能会有改变，建议还是用jmap首先观察下目前每个代的内存大小、GC方式）

3）运行状况监测工具：jstat、jvisualvm、sar、gclogviewer

2、应收集的信息

1）minor gc的执行频率；full gc的执行频率，每次GC耗时多少？

2）高峰期什么状况？

3）minor gc回收的效果如何？survivor的消耗状况如何，每次有多少对象会进入老生代？4）full gc回收的效果如何？（简单的memory leak判断方法）

5）系统的load、cpu消耗、qps or tps、响应时间

QPS每秒查询率：是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。在因特网上，作为域名服务器的机器性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。

TPS(Transaction Per Second)：每秒钟系统能够处理的交易或事务的数量。

尝试调优：

注意Java RMI的定时GC触发机制，可通过：-XX:+DisableExplicitGC来禁止或通过-Dsun.rmi.dgc.server.gcInterval=3600000来控制触发的时间。

1）降低Full GC执行频率–通常瓶颈

老生代本身占用的内存空间就一直偏高，所以只要稍微放点对象到老生代，就full GC了；通常原因：系统缓存的东西太多；

例如：使用oracle 10g驱动时preparedstatement cache太大；

查找办法：现执行Dump然后再进行MAT分析；

（1）Minor GC后总是有对象不断的进入老生代，导致老生代不断的满

通常原因：Survivor太小了

系统表现：系统响应太慢、请求量太大、每次请求分配的内存太多、分配的对象太大...

查找办法：分析两次minor GC之间到底哪些地方分配了内存；

利用jstat观察Survivor的消耗状况，-XX:PrintHeapAtGC，输出GC前后的详细信息；对于系统响应慢可以采用系统优化，不是GC优化的内容；

（2）老生代的内存占用一直偏高

调优方法：①扩大老生代的大小（减少新生代的大小或调大heap的大小）；

减少new注意对minor gc的影响并且同时有可能造成full gc还是严重；

调大heap注意full gc的时间的延长，cpu够强悍嘛，os是32 bit的吗？

②程序优化（去掉一些不必要的缓存）

（3）Minor GC后总是有对象不断的进入老生代

前提：这些进入老生代的对象在full GC时大部分都会被回收

调优方法：

①降低Minor GC的执行频率；

②让对象尽量在Minor GC中就被回收掉：增大Eden区、增大survivor、增大TenuringThreshold；注意这些可能会造成minor gc执行频繁；

③切换成CMS GC：老生代还没有满就回收掉，从而降低Full GC触发的可能性；

④程序优化：提升响应速度、降低每次请求分配的内存、

（4）降低单次Full GC的执行时间

通常原因：老生代太大了...

调优方法：1）是并行GC吗？2）升级CPU 3）减小Heap或老生代

（5）降低Minor GC执行频率

通常原因：每次请求分配的内存多、请求量大

通常办法：1）扩大heap、扩大新生代、扩大eden。注意点：降低每次请求分配的内存；横向增加机器的数量分担请求的数量。

（6）降低Minor GC执行时间

通常原因：新生代太大了，响应速度太慢了，导致每次Minor GC时存活的对象多

通常办法：1）减小点新生代吧；2）增加CPU的数量、升级CPU的配置；加快系统的响应速度

细微调整：

首先需要了解以下情况：

①当响应速度下降到多少或请求量上涨到多少时，系统会宕掉？

②参数调整后系统多久会执行一次Minor GC，多久会执行一次Full GC，高峰期会如何？需要计算的量：

①每次请求平均需要分配多少内存？系统的平均响应时间是多少呢？请求量是多少、多常时间执行一次Minor GC、Full GC？

②现有参数下，应该是多久一次Minor GC、Full GC，对比真实状况，做一定的调整；

必杀技：提升响应速度、降低每次请求分配的内存？

9、系统调优举例

现象：1、系统响应速度大概为100ms；2、当系统QPS增长到40时，机器每隔5秒就执行一次minor gc，每隔3分钟就执行一次full gc，并且很快就一直full GC了；4、每次Full gc后旧生代大概会消耗400M，有点多了。

解决方案：解决Full GC次数过多的问题

（1）降低响应时间或请求次数，这个需要重构，比较麻烦；——这个是终极方法，往往能够顺利的解决问题，因为大部分的问题均是由程序自身造成的。

（2）减少老生代内存的消耗，比较靠谱；——可以通过分析Dump文件（jmap dump），并利用MAT查找内存消耗的原因，从而发现程序中造成老生代内存消耗的原因。

（3）减少每次请求的内存的消耗，貌似比较靠谱；——这个是海市蜃楼，没有太好的办法。

（4）降低GC造成的应用暂停的时间——可以采用CMS GS垃圾回收器。参数设置如下：

-Xms1536m -Xmx1536m -Xmn700m -XX:SurvivorRatio=7 -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection

-XX:CMSMaxAbortablePrecleanTime=1000 -XX:+CMSClassUnloadingEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:+DisableExplicitGC

（5）减少每次minor gc晋升到old的对象。可选方法：1）调大新生代。2）调大Survivor。3）调大TenuringThreshold。

调大Survivor：当前采用PS GC，Survivor space会被动态调整。由于调整幅度很小，导致了经常有对象直接转移到了老生代；于是禁止Survivor区的动态调整了，

-XX:-UseAdaptiveSizePolicy，并计算Survivor Space需要的大小，于是继续观察，并做微调…。最终将Full GC推迟到2小时1次。

10、垃圾回收的实现原理

内存回收的实现方法：1）引用计数：不适合复杂对象的引用关系，尤其是循环依赖的场景。2）有向图Tracing：适合于复杂对象的引用关系场景，Hotspot采用这种。常用算法：Copying、Mark-Sweep、Mark-Compact。

Hotspot从root set开始扫描有引用的对象并对Reference类型的对象进行特殊处理。

以下是Root Set的列表：1）当前正在执行的线程；2）全局/静态变量；3）JVM Handles；4）JNI 【Java Native Interface 】Handles；

另外：minor GC只扫描新生代，当老生代的对象引用了新生代的对象时，会采用如下的处理方式：在给对象赋引用时，会经过一个write barrier的过程，以便检查是否有老生代引用新生代对象的情况，如有则记录到remember set中。并在minor gc时，remember set指向的新生代对象也作为root set。

新生代串行GC(Serial Copying)：

新生代串行GC(Serial Copying)完整内存的分配策略：

1）首先在TLAB（本地线程分配缓冲区）上尝试分配；

2）检查是否需要在新生代上分配，如需要分配的大小小于PretenureSizeThreshold，则在eden区上进行分配，分配成功则返回；分配失败则继续；

3）检查是否需要尝试在老生代上分配，如需要，则遍历所有代并检查是否可在该代上分配，如可以则进行分配；如不需要在老生代上尝试分配，则继续；

4）根据策略决定执行新生代GC或Full GC，执行full gc时不清除soft Ref；

5）如需要分配的大小大于PretenureSizeThreshold，尝试在老生代上分配，否则尝试在新生代上分配；

6）尝试扩大堆并分配；

7）执行full gc，并清除所有soft Ref，按步骤5继续尝试分配。

新生代串行GC(Serial Copying)完整内存回收策略

1）检查to是否为空，不为空返回false；

2）检查老生代剩余空间是否大于当前eden+from已用的大小，如大于则返回true，如小于且HandlePromotionFailure为true，则检查剩余空间是否大于之前每次minor gc 晋级到老生代的平均大小，如大于返回true，如小于返回false。

3）如上面的结果为false，则执行full gc；如上面的结果为true，执行下面的步骤；

4）扫描引用关系，将活的对象copy到to space，如对象在minor gc中的存活次数超过tenuring_threshold或分配失败，则往老生代复制，如仍然复制失败，则取决于

HandlePromotionFailure，如不需要处理，直接抛出OOM，并退出vm，如需处理，则保持这些新生代对象不动；

新生代可用GC-PS

完整内存分配策略

1）先在TLAB上分配，分配失败则直接在eden上分配；

2）当eden上分配失败时，检查需要分配的大小是否>= eden space的一半，如是，则直接在老生代分配；

3）如分配仍然失败，且gc已超过频率，则抛出OOM；

4）进入基本分配策略失败的模式；

5）执行PS GC，在eden上分配；

6）执行非最大压缩的full gc，在eden上分配；

7）在旧生代上分配；

8）执行最大压缩full gc，在eden上分配；

9）在旧生代上分配；

10）如还失败，回到2。

最悲惨的情况，分配触发多次PS GC和多次Full GC，直到OOM。

完整内存回收策略

1）如gc所执行的时间超过，直接结束；

2）先调用invoke_nopolicy

2.1 先检查是不是要尝试scavenge；

2.1.1 to space必须为空，如不为空，则返回false；

2.1.2 获取之前所有minor gc晋级到old的平均大小，并对比目前eden+from已使用的大小，取更小的一个值，如老生代剩余空间小于此值，则返回false，如大于则返回true；

2.2 如不需要尝试scavenge，则返回false，否则继续；

2.3 多线程扫描活的对象，并基亍copying算法回收，回收时相应的晋升对象到旧生代；

2.4 如UseAdaptiveSizePolicy，那么重新计算to space和tenuringThreshold 的值，并调整。

3）如invoke_nopolicy返回的是false，或之前所有minor gc晋级到老生代的平均大小>旧生代的剩余空间，那么继续下面的步骤，否则结束；

4）如UseParallelOldGC，则执行PSParallelCompact，如不是UseParallelOldGC，则执行PSMarkSweep。

老生代并行CMS GC：

优缺点：

1）大部分时候和应用并发进行，因此只会造成很短的暂停时间；

2）浮动垃圾，没办法，所以内存空间要稍微大一点；

3）内存碎片，-XX:+UseCMSCompactAtFullCollection来解决；

4）争抢CPU，这GC方式就这样；

5）多次remark，所以总的gc时间会比并行的长；

6）内存分配，free list方式，so性能稍差，对minor GC会有一点影响；

7）和应用并发，有可能分配和回收同时，产生竞争，引入了锁，JVM分配优先。11、TLAB的解释

堆内的对象数据是各个线程所共享的，所以当在堆内创建新的对象时，就需要进行锁操作。锁操作是比较耗时，因此JVM为每个线在堆上分配了一块―自留地‖——TLAB(全称是Thread Local Allocation Buffer)，位于堆内存的新生代，也就是Eden区。每个线程在创建新的对象时，会首先尝试在自己的TLAB里进行分配，如果成功就返回，失败了再到共享的Eden区里去申请空间。在线程自己的TLAB区域创建对象失败一般有两个原因：一是对象太大，二是自己的TLAB区剩余空间不够。通常默认的TLAB区域大小是Eden区域的1%，当然也可以手工进行调整，对应的JVM参数是

了解JVM的系统结构，再来看看JVM内存回收问题了——

Sun的JVM Generational Collecting(垃圾回收)原理是这样的：把对象分为年青代(Young)、年老代(Tenured)、持久代(Perm)，对不同生命周期的对象使用不同的算法。(基于对对象生命周期分析)

如上图所示，为Java堆中的各代分布。

1. Young（年轻代）

年轻代分三个区。一个Eden 区，两个Survivor区。大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当这个Survivor 区满时，此区的存活对象将被复制到另外一个Survivor区，当这个Survivor去也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，将被复制年老区(Tenured。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时存在从Eden复制过来对象，和从前一个Survivor复制过来的对象，而复制到年老区的只有从第一个Survivor去过来的对象。而且，Survivor区总有一个是空的。

2. Tenured（年老代）

年老代存放从年轻代存活的对象。一般来说年老代存放的都是生命期较长的对象。

3. Perm（持久代）

用于存放静态文件，如今Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代大小通过-XX:MaxPermSize=进行设置。

举个例子：当在程序中生成对象时，正常对象会在年轻代中分配空间，如果是过大的对象也可能会直接在年老代生成（据观测在运行某程序时候每次会生成一个十兆的空间用收发消息，这部分内存就会直接在年老代分配）。年轻代在空间被分配完的时候就会发起内存回收，大部分内存会被回收，一部分幸存的内存会被拷贝至Survivor的from区，经过多次回收以后如果from区内存也分配完毕，就会也发生内存回收然后将剩余的对象拷贝至to区。等到to区也满的时候，就会再次发生内存回收然后把幸存的对象拷贝至年老区。

通常我们说的JVM内存回收总是在指堆内存回收，确实只有堆中的内容是动态申请分配的，所以以上对象的年轻代和年老代都是指的JVM的Heap空间，而持久代则是之前提到的Method Area，不属于Heap。

了解完这些之后，以下的转载一热衷于钻研技术的哥们Richen Wang关于内存管理的一些建议——

1、手动将生成的无用对象，中间对象置为null，加快内存回收。

2、对象池技术如果生成的对象是可重用的对象，只是其中的属性不同时，可以考虑采用对象池来较少对象的生成。如果有空闲的对象就从对象池中取出使用，没有再生成新的对象，大大提高了对象的复用率。

3、JVM调优通过配置JVM的参数来提高垃圾回收的速度，如果在没有出现内存泄露且上

面两种办法都不能保证内存的回收时，可以考虑采用JVM调优的方式来解决，不过一定要经过实体机的长期测试，因为不同的参数可能引起不同的效果。如-Xnoclassgc参数等。