你的位置:首页 > 信息动态 > 新闻中心
信息动态
联系我们

JVM 调优及内存泄漏

2021-11-29 18:38:01

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 减小单个线程大小。以便能生产 更多的线程。