JVM 调优及内存泄漏

JVM 内存管理 JVM 将内存划分为 6 个部分：PC 寄存器（也叫程序计数器）.虚拟机栈.堆. 方法区.运行时常量池.本地方法栈 

1. PC 寄存器（程序计数器）：
用于记录当前线程运行时的位置，每一 个线程都有一个独立的程序计数器，线程的阻塞.恢复.挂起等一系列操作都 需要程序计数器的参与，因此必须是线程私有的。

2. java 虚拟机栈：在创建线程时创建的，用来存储栈帧，因此也是线 程私有的。java 程序中的方法在执行时，会创建一个栈帧，用于存储方法 运行时的临时数据和中间结果，包括局部变量表.操作数栈.动态链接.方法 出口等信息。这些栈帧就存储在栈中。如果栈深度大于虚拟机允许的最大深 度，则抛出 StackOverflowError 异常。

局部变量表：方法的局部变量列表，在编译时就写入了 class 文件
操作数栈：int x = 1; 就需要将 1 压入操作数栈，再将 1 赋值给变量 x

3. java 堆：java 堆被所有线程共享，堆的主要作用就是存储对象。如 果堆空间不够，但扩展时又不能申请到足够的内存时，则抛出 OutOfMemory Error 异常。 StackOverflowError OutOfMemoryError

4. 方法区：方发区被各个线程共享，用于存储静态变量.运行时常量池 等信息。

5. 本地方法栈：本地方法栈的主要作用就是支持 native 方法，比如在 java 中调用 C/C+

GC 分代收集算法和分区收集算法区别?

1. 分代收集算法

当前主流 VM 垃圾收集都采用”分代收集”(Generational Collection)算法, 这种算法会根
据对象存活周期的不同将内存划分为几块, 如 JVM 中的 新生代、老年代、永久代，这样就可以根据 各年代特点分别采用最适当的 GC 算法

在新生代-复制算法 ：每次垃圾收集都能发现大批对象已死, 只有少量存活 . 因此选用复制算法, 只需要付出少量 存活对象的复制成本就可以完成收集

在老年代-标记整理算法 ：因为对象存活率高、没有额外空间对它进行分配担保, 就必须采用“标记—清理”或“标 记 —整理”算法来进行回收, 不必进行内存复制, 且直接腾出空闲内存

2. 分区收集算法

分区算法则将整个堆空间划分为连续的不同小区间, 每个小区间独立使用, 独立回收 . 这样做的好处是可以控制一次回收多少个小区间 ,
根据目标停顿时间, 每次合理地回收若干个小 区间(而不是 整个堆), 从而减少一次 GC 所产生的停顿。

GC 垃圾收集器

Java 堆内存被划分为新生代和年老代两部分，新生代主要使用复制和标记-清除垃圾回收算 法； 年老代主要使用标记-整理垃圾回收算法，因此 java 虚拟中针对新生代和年老代分别提供了多 种不 同的垃圾收集器，JDK1.6 中 Sun HotSpot 虚拟机的垃圾收集器如下.

常见的垃圾回收器:Serial 垃圾收集器（单线程、复制算法）,ParNew 垃圾收集器 （Serial+多线程）,Parallel
Scavenge 收集器（多线程复制算法、高效）等

最常用的是 G1(Garbage First):

G1 是一个面向服务端的 JVM 垃圾收集器，适用于多核处理器、大内存容量的服务 端系统。 它满足短时间停顿的同时达到一个高的吞吐量。从
JDK 9 开始，G1 成为默认的垃 圾回收器。当应用有以下任何一种特性时非常适合用 G1

1. Full GC 持续时间太长或者太频繁
2. 对象的创建速率和存活率变动很大
3. 应用不希望停顿时间长(长于 0.5s 甚至 1s)

JVM 调优工具

Jconsole，jProfile，VisualVM

Jconsole :

jdk 自带，功能简单，但是可以在系统有一定负荷的情况下使 用。对垃圾回收算法有很详细的跟踪。

JProfiler：

商业软件，需要付费。功能强大。

VisualVM：

JDK 自带，功能强大，与 JProfiler 类似。推荐。

如何调优

在 CPU 负载不足的同时，偶尔会有用户反映请求的时间过长，我们意识到必 须对程序及 JVM 进行调优。从以下几个方面进行：

1. 线程池：解决用户响应时间长的问题
2. JVM 启动参数：调整各代的内存比例和垃圾回收算法，提高吞吐量 程序算法：改进程序逻辑算法提高性能

内存泄漏检查

内存泄漏是比较常见的问题，而且解决方法也比较通用，这里可以 重点说一下，而线程.热点方面的问题则是具体问题具体分析了。
内存泄漏一般可以理解为系统资源（各方面的资源，堆.栈.线程等） 在错误使用的情况下，导致使用完毕的资源无法回收（或没有回收），从而导致
新的资源分配请求无法完成，引起系统错误。 内存泄漏对系统危害比较大，因为他可以直接导致系统的崩溃。
需要区别一下，内存泄漏和系统超负荷两者是有区别的，虽然可能 导致的最终结果是一样的。内存泄漏是用完的资源没有回收引起错误，而系统超
负荷则是系统确实没有那么多资源可以分配了（其他的资源都在使用）。

年老代堆空间被占满 异常： java.lang.OutOfMemoryError: Java heap space
说明：

这是最典型的内存泄漏方式，简单说就是所有堆空间都被无法回收 的垃圾对象占满，虚拟机无法再在分配新空间。
如上图所示，这是非常典型的内存泄漏的垃圾回收情况图。所有峰 值部分都是一次垃圾回收点，所有谷底部分表示是一次垃圾回收后剩余的内存。
连接所有谷底的点，可以发现一条由底到高的线，这说明，随时间的推移，系统
的堆空间被不断占满，最终会占满整个堆空间。因此可以初步认为系统内部可能
有内存泄漏。（上面的图仅供示例，在实际情况下收集数据的时间需要更长，比 如几个小时或者几天）

解决： 这种方式解决起来也比较容易，一般就是根据垃圾回收前后情况对 比，同时根据对象引用情况（常见的集合对象引用）分析，基本都可以找到泄漏 点。

持久代被占满 异常：java.lang.OutOfMemoryError: PermGen space
说明：

Perm 空间被占满。无法为新的 class 分配存储空间而引发的异常。 这个异常以前是没有的，但是在 Java
反射大量使用的今天这个异常比较常见了。 主要原因就是大量动态反射生成的类不断被加载，最终导致 Perm 区被占满。 更可怕的是，不同的
classLoader 即便使用了相同的类，但是都会 对其进行加载，相当于同一个东西，如果有 N 个 classLoader
那么他将会被加载 N 次。因此，某些情况下，这个问题基本视为无解。当然，存在大量 classLoader 和大量反射类的情况其实也不多。

解决：

1. -XX:MaxPermSize=16m
2. 换用 JDK。比如 JRocket。

堆栈溢出 异常：java.lang.StackOverflowError

说明：

这个就不多说了，一般就是递归没返回，或者循环调用造成

线程堆栈满 异常：Fatal: Stack size too small
说明：

java 中一个线程的空间大小是有限制的。JDK5.0 以后这个值是 1M。
与这个线程相关的数据将会保存在其中。但是当线程空间满了以后，将会出现上 面异常。

解决：增加线程栈大小。-Xss2m。但这个配置无法解决根本问题，还要看代 码部分是否有造成泄漏的部分。

系统内存被占满 异常：java.lang.OutOfMemoryError: unable to create new native thread
说明：

这个异常是由于操作系统没有足够的资源来产生这个线程造成的。 系统创建线程时，除了要在 Java 堆中分配内存外，操作系统本身也需要分配资
源来创建线程。因此，当线程数量大到一定程度以后，堆中或许还有空间，但是 操作系统分配不出资源来了，就出现这个异常了。 分配给 Java
虚拟机的内存愈多，系统剩余的资源就越少，因此，当系统内 存固定时，分配给 Java 虚拟机的内存越多，那么，系统总共能够产生的线程也
就越少，两者成反比的关系。同时，可以通过修改-Xss 来减少分配给单个线程 的空间，也可以增加系统总共内生产的线程数。

解决：

1. 重新设计系统减少线程数量。
2. 线程数量不能减少的情况下，通过-Xss 减小单个线程大小。以便能生产 更多的线程。