JVM性能调优

最新推荐文章于 2025-05-30 15:59:13 发布
转载 最新推荐文章于 2025-05-30 15:59:13 发布 · 353 阅读 · 0 ·
CC 4.0 BY-SA版权
原文链接：https://my.oschina.net/OQKuDOtsbYT2/blog/200790
文章标签：

#运维 #runtime #开发工具

本文详细介绍了JVM内存结构，包括堆、方法区、栈等，并讲解了垃圾回收算法及调优实践，帮助读者理解JVM内存管理。

推荐GameKing的JVM学习笔记系列 和 cprime，更加细致


0.JVM体系结构简介

JVM Specification中的JVM整体架构

　　主要包括两个子系统和两个组件，Class Loader(类装载)子系统，Execution Engine(执行引擎)子系统，Runtime Data Area(运行时数据区)组件，Native Interface(本地接口)组件。

　　Class loader 子系统的作用 ：根 据给定的全限定名类名(如 java.lang.Object)来装载class文件的内容到 Runtime data area 中的method area(方法区域)。Java 程序员可以extends java.lang.ClassLoader 类来写自己的Class loader。

　　Execution engine 子系统的作用 ：执 行 classes中的指令。任何 JVM specification实现(JDK)的核心是Execution engine， 换句话说：Sun 的JDK 和IBM的JDK好坏主要取决于他们各自实现的Execution  engine的好坏。每个运行中的线程都有一个 Execution engine的实例。 

　　Native interface 组件 ：与native libraries 交互，是其它编程语言交互的接口。 

　　Runtime data area 组件：这个组件就是 JVM中的内存。

 

Runtime data area 的整体架构图

　　Runtime data area 主要包括五个部分：Heap (堆), Method Area(方法区域), Java Stack(java 的栈), Program Counter(程序计数器), Native method stack(本地方法栈)。Heap 和Method Area 是被所有线程的共享使用的；而Java stack, Program counter 和 Native method stack 是以线程为粒度的，每个线程独自拥有。

Heap 

　 　Java程序在运行时创建的所有类实例或数组都放在同一个堆中。而一个Java虚拟实例中只存在一个堆空间，因此所有线程都将共享这个堆。每一个 java程序独占一个JVM实例，因而每个 java程序都有它自己的堆空间，它们不会彼此干扰。但是同一java程序的多个线程都共享着同一个堆空间，就得考虑多线程访问对象（堆数据）的同步问 题。（这里可能出现的异常 java.lang.OutOfMemoryError: Java heap space） 

Method area 

　 　在Java 虚拟机中，被装载的 class的信息存储在 Method area的内存中。当虚拟机装载某个类型时，它使用类装载器定位相应的 class文件，然后读入这个class文件内容并把它传输到虚拟机中。紧接着虚拟机提取其中的类型信息，并将这些信息存储到方法区。该类型中的类（静 态）变量同样也存储在方法区中。与Heap 一样，method area 是多线程共享的，因此要考虑多线程访问的同步问题。比如，假设同时两个线程都企图访问一个名为 Lava的类，而这个类还没有内装载入虚拟机，那么，这时应该只有一个线程去装载它，而另一个线程则只能等待。 （这里可能出现的异常 java.lang.OutOfMemoryError: PermGen full）

Java stack 

　 　Java stack 以帧为单位保存线程的运行状态。虚拟机只会直接对 Java stack执行两种操作：以帧为单位的压栈或出栈。每当线程调用一个方法的时候，就对当前状态作为一个帧保存到 java stack 中(压栈)；当一个方法调用返回时，从java stack 弹出一个帧(出栈)。栈的大小是有一定的限制，这个可能出现StackOverFlow 问题，例如递归的层数太深。

Program counter  

　　每个运行中的Java程序，每一个线程都有它自己的PC寄存器，也是该线程启动时创建的。PC寄存器的内容总是指向下一条将被执行指令的地址，这里的地址可以是一个本地指针，也可以是在方法区中相对应于该方法起始指令的偏移量。  

Native method stack  

　 　对于一个运行中的Java程序而言，它还能会用到一些跟本地方法相关的数据区。当某个线程调用一个本地方法时，它就进入了一个全新的并且不再受虚拟机限 制的世界。本地方法可以通过本地方法接口来访问虚拟机的运行时数据区，不止如此，它还可以做任何它想做的事情。比如，可以调用寄存器，或在操作系统中分配 内存等。总之，本地方法具有和JVM 相同的能力和权限。  (这里出现 JVM无法控制的内存溢出问题 native heap OutOfMemory ) 。

Sun JVM 中对 JVM Specification 的实现（内存部分）   

　 　JVM Specification只是抽象的说明了 JVM 实例按照子系统、内存区、数据类型以及指令这几个术语来描述的，  但是规范并非是要强制规定 Java 虚拟机实现内部的体系结构，更多的是为了严格地定义这些实现的外部特征。  Sun JVM 实现中：Runtime data area(JVM  内存)  五个部分中的 Java Stack , Program Counter, Native method stack 三部分和规范中的描述基本一致；但对 Heap  和  Method Area 进行了自己独特的实现。这个实现和 Sun JVM  的Garbage collector（垃圾回收）机制有关。  

垃圾分代回收算法（Generational Collecting）  

　　基于对对象生命周期分析后得出的垃圾回收算法。把对象分为年青代、年老代、持久代，对不同生命周期的对象使用不同的算法（上述方式中的一个）进行回收。现在的垃圾回收器（从J2SE1.2开始）都是使用此算法的。 

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

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

　　2. Tenured（年老代）JVM specification中的  Heap的一部分。年老代存放从年轻代存活的对象。一般来说年老代存放的都是生命期较长的对象。

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


1.内存分代

JVM的内存分代管理结构：

JVM Tunning Practice(1) - 内存分代 - Harry - 染出一道彩虹

下面是一些需要关注的常用的JVM内存配置参数，我们来看看它们是如何影响上图中的比例的。

1）Heap Size

-Xmx ---最大Heap Size，即上图的Total size（包括Eden+form+to，Tenured，不包含Perm，见上图），限制了年轻代和年老代的可分配最大值；

-Xms ---初始化分配的Heap Size

生产环境中ms一般设置成跟mx相等，因为若ms不等于mx那么在某些场景下JVM可能需要对Heap Size进行频繁的扩展和收缩，增加处理时间；

2）New/Young Generation Size

-Xmn ---最大年轻代大小，即上图中的Eden+S0+S1+Virtual

-XX:NewSize ---初始化年轻代大小，即上图中的Eden+S0+S1，在只设置了-Xmn不设置-XX:NewSize的情况下，NewSize等于mn。

生产环境中一般只需设置-Xmn或者设置mn和NewSize相等，理由和HeapSize的设置一样，避免容量震荡消耗资源；

3）Old Generation Size （Tenured）

-XX:NewRatio --- Old Size/New Size，通过年老代和年轻代的比例和Heap Size就可以算出年老代的大小。一般默认为8，若Heap Size为1024m，则 NewSize=HeapSize/(NewRatio+1)=114m，OldSize=HeapSize-NewSize=910m；

注意：-Xmn的优先级比-XX:NewRatio高，若-Xmn已指定，则OldSize=HeapSize-NewSize，无需再按比例计算。生产环境中一般只需指定-Xmn就足够了。

4）Eden和S0、S1

-XX:SurvivorRatio --- Eden/S0，即 Eden区和S0的比例，默认为8，若NewSize为114m，则S0=NewSize/(SurvivorRatio+2)=11.4m;

S0==S1，S0、S1的职能是一模一样的，又叫做From space和To space，在每一次minor gc后角色会交换。

注意：-XX类型的选项在不同的JDK版本或实现中定义可能有所区别，在近日的实践中发现，

在Linux jdk_1_5_0_10_x86版本中，SurvivorRatio=(YoungSize/S0)，而Linux jdk_1_5_0_20_x64版本中，SurvivorRatio=(Eden/S0)

所以，我们在实际的工程实践中还是应该用jmap -heap输出的jvm内存结构信息为准，不要想当然。

5）Permanent Generation Size

-XX:MaxPermSize ---最大持久代大小，默认为64m；

-XX:PermSize ---初始化持久代大小，默认为16m；

生产环境中一般设置MaxPermSize和PermSize相等，理由和HeapSize的设置一样，避免容量震荡消耗资源；

当应用引用的类比较多或者应用了一些动态类生产技术时应该加大该区的值，一般256m对服务器程序都很足够了。


下面是一些JVM对Native Memory内存的使用：

6）Thread Stack Size

-Xss ---线程堆栈大小，一般用于存放方法入口参数和返回值，以及原子类型的本地变量（即方法内部变量）；

一般可设置为128k.

7）Direct Memory Size

-XX:MaxDirectMemorySize ---direct byte buffer用到的本地内存，在本blog的一篇《xsocket内存泄漏》文章中介绍过该参数的作用。默认跟mx相等，所以生产环境中一般不设置mx大于物理内存的一半。

2.GC过程  

在讲述GC过程前我先解释一下JVM的两个控制参数：

-XX:TargetSurvivorRatio --- Survivor Space最大使用率，若存放对象的总大小超过该值，将引起对象向Old区迁移；

-XX:MaxTenuringThreshold --- Young区对象的最大任期阀值，即可经历minor gc的次数，超过该次数的对象直接迁移到Old区；

实际的TenuringThreshold由JVM通过Survivor Space的占用率和TargetSurvivorRatio动态计算，详情请查看参考资料。

《HP-MemoryManagement.pdf》中有对JVM GC过程的形象描述，我借用其中的一些图例来说明一下。

1）Heap在初始状态

JVM Tunning Practice(2) - GC过程 - Harry - 染出一道彩虹

2）在Eden存放新对象

JVM Tunning Practice(2) - GC过程 - Harry - 染出一道彩虹

3）Eden空间不足分配新对象，进行第一次minor gc

JVM Tunning Practice(2) - GC过程 - Harry - 染出一道彩虹

JVM Tunning Practice(2) - GC过程 - Harry - 染出一道彩虹

JVM Tunning Practice(2) - GC过程 - Harry - 染出一道彩虹

4) Eden区再次被写满，进行第二次minor gc

JVM Tunning Practice(2) - GC过程 - Harry - 染出一道彩虹

JVM Tunning Practice(2) - GC过程 - Harry - 染出一道彩虹

JVM Tunning Practice(2) - GC过程 - Harry - 染出一道彩虹

JVM Tunning Practice(2) - GC过程 - Harry - 染出一道彩虹

5)Eden再次被写满，进行第3次minor gc

第3次gc，发生了对象从from space提升到old区的迁移，然后也发生了from space到to space的copy

JVM Tunning Practice(2) - GC过程 - Harry - 染出一道彩虹

JVM Tunning Practice(2) - GC过程 - Harry - 染出一道彩虹

JVM Tunning Practice(2) - GC过程 - Harry - 染出一道彩虹

JVM Tunning Practice(2) - GC过程 - Harry - 染出一道彩虹

JVM Tunning Practice(2) - GC过程 - Harry - 染出一道彩虹

JVM Tunning Practice(2) - GC过程 - Harry - 染出一道彩虹

以下是Survivor space空间不足但对象的minor gc次数未到达MaxTenuringThreshold时的gc情况：

JVM Tunning Practice(2) - GC过程 - Harry - 染出一道彩虹

JVM Tunning Practice(2) - GC过程 - Harry - 染出一道彩虹

JVM Tunning Practice(2) - GC过程 - Harry - 染出一道彩虹

3.GC实战  

在进行GC Tuning时有两个很强大的利器：

jstat：用于查看某java进程的gc情况；

jmap：查看java进程堆栈分配和使用情况，以及dump出当前堆栈内容（可以用Eclipse MAT进行进一步分析）

以上两个利器都是jdk自带，且无需java进程添加任何额外的debug信息输出参数的，直接就可以对任意java进程进行跟踪了。


       我认为GC调优的整体目标是要减缓GC的总体时间增加和降低每次gc引起的应用停顿（大概就是每次执行gc消耗的时间）。但往往我们只能在两者间获取一个平衡，在吞吐量和应用暂停时间之间取得一个平衡。

JVM Tunning Practice(2) - GC Tunning - Harry - 染出一道彩虹

JVM Tunning Practice(2) - GC Tunning - Harry - 染出一道彩虹

JVM Tunning Practice(2) - GC Tunning - Harry - 染出一道彩虹

调优前配置：-Xmx1024m -Xms1024m

调优前gc情况：jstat -gcutil <pid> 3000

minor gc: 3~6次/3秒

full gc: 1次/30秒


调优后配置：-Xmx2g -Xms2g -Xmn1g -Xss128k -XX:NewSize=1g -XX:PermSize=128m

-XX:MaxPermSize=256m -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=60 

-XX:MaxTenuringThreshold=20 -XX:+UseParNewGC -XX:ParallelGCThreads=8 -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=80 -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0

调优后gc情况：

minor gc: 1次/15秒

full gc: 1次/数小时到数十小时


UseParNewGC表示对新生代采用并行gc；

ParallelGCThreads表示并行的线程数为8，一般是cpu的核个数，当核个数大于8时可能不是很适用；

UseConcMarkSweepGC表示对full gc采用CMS gc；


另外还有几个跟GC有关的有用参数，这里没有用到：

-XX:+DisableExplicitGC 表示禁止显式gc，System.gc()

-XX:+UseCMSCompactAtFullCollection 适用于CMS gc，表示在进行gc的同时清理内存碎片，但会加长gc的总时间

-XX:CMSInitiatingOccupancyFraction=80 适用于CMS gc，表示在年老代达到80%使用率时马上进行回收


另外下面是在JVM Crash时获heap信息的一些配置参数：

-XX:ErrorFile=./xxx.log   JVM Crash时记录heap信息

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./yyy.log JVM OOM时记录heap信息

拿到heap文件后可以用Eclipse MAT进行分析，找出引起内存泄漏的class。


参考资料：

1）HP-MemoryManagement.pdf

2）http://www.51testing.com/?uid-77492-action-viewspace-itemid-203728

3）http://sunqi.javaeye.com/blog/486048

4）http://fallenlord.blogbus.com/logs/57543373.html


转载于:https://my.oschina.net/OQKuDOtsbYT2/blog/200790

chimu9074
关注
JVM基础知识（四）- 分代回收机制和垃圾回收算法
王小汪的博客
07-29 506
这次我们来讲讲垃圾回收，前边或多或少的都提及过垃圾回收的知识点，我们经常说的GC（Garbage Collection）就是垃圾回收，我们都知道JAVA都是由C++演化而来，那么JAVA和C++很重要的一点不同就是自动分配内存和自动回收内存，这两块已经不需要JAVA开发者来操心。但是GC对性能是有影响的，有时候会暂停所有的线程，触发STW（Stop the world），所以GC是把双刃剑。那么一般情况下，垃圾回收的重点是在堆区，栈区是随线程的消亡而消亡的，不需要垃圾回收器去管理，方法区虽说可以进行垃圾回收
JVM学习记录（六）——垃圾收集之分代回收机制
weixin_45974176的博客
01-24 698
引言 本博客根据《深入理解Java虚拟机：JVM高级特性与最佳实践（第3版） 周志明》这本书，加上查阅其他资料理解创作而成（可能有些不准确，请理解），希望能对你有帮助。 举例讲解 Java对象的一生：我是一个java对象，我出生在Eden区。在Eden区有一些跟我一样的兄弟们，我们在Eden区中一起玩，每天都有新的兄弟进来。有一天Eden区中的人实在是太多了，我就被迫去了Survivor区的“From”区，自从去了Survivor区，在这里生活非常不稳定。有时候在Survivor的“From”区，有时
Java jvm 分代回收算法（Generational Garbage Collection）
qq_35082497的博客
02-21 933
是现代 JVM 中垃圾回收的核心思想，通过将堆划分为多个区域（年轻代、老年代等），针对每个区域采用不同的垃圾回收策略，以提高回收效率并减少停顿时间。不同的垃圾回收器（如 Serial GC、Parallel GC、CMS GC、G1 GC）根据分代回收的理念实现了不同的回收策略，适应不同的应用需求。分代回收使得大多数对象能够在年轻代快速回收，从而提高了应用程序的响应速度。
JVM分代回收机制和垃圾回收算法
羽毛的博客
03-08 589
JVM系列文章目录 初识JVM 深入理解JVM内存区域 玩转JVM对象和引用 JVM分代回收机制和垃圾回收算法JVM系列文章目录分代回收机制分代回收基础知识垃圾回收算法复制算法(Copying)普通的复制算法JVM中的复制回收算法标记-清除算法(Mark-Sweep)标记-整理算法（Mark-Compact）JVM中常见的垃圾回收器单线程垃圾回收器多线程垃圾回收器Parallel Scavenger + Parallel OldParNewCMS（Concurrent Mark Sweep ）G1（G
jvm分代回收机制
09-21 2364
虚拟机中的共划分为三个代：年轻代（Young Generation）、年老点（Old Generation）和持久代（Permanent Generation）。其中持久代主要存放的是Java类的类信息，与垃圾收集要收集的Java对象关系不大。年轻代和年老代的划分是对垃圾收集影响比较大的。 　　年轻代: 　　所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生
深入理解Java虚拟机（jvm性能调优+内存模型+虚拟机原理）.zip
09-27
《深入理解Java虚拟机》是一本深度探讨Java虚拟机（JVM）的著作，涵盖了JVM性能调优、内存模型以及虚拟机原理等多个关键领域。本文将基于这些主题，详细阐述其中的重要知识点。 首先，我们要了解Java虚拟机（JVM）...
JVM 性能调优 -- 线上应用 JVM 内存调优【实战】
weixin_42118323的博客
11-22 1900
相信懂与不懂的朋友都会回答不是，确实不是年轻代空间越大越好，老祖宗说过物极必反，JVM 也在堆中进行分带设计，进行分代设计必然是有原因的，我们知道 Minor GC 效率高，那 Minor GC 效率为啥高，这里面有一个根本原因就是年轻代的空间也会相对较小（当然也跟年轻代采用的垃圾回收算法等有关系），试想一下，如果年轻代空间足够大，在进行垃圾回收的时候，单单就标记 GC ROOTS 就需要消耗大量时间，最终在进行垃圾回收的时候同样也要消耗大量时间，如此以来跟 Full GC 又有什么区别呢。
JVM性能调优实战项目.zip
最新发布
11-17
在深入探究JVM性能调优实战项目之前，我们首先需要了解JVM（Java虚拟机）的基本概念。JVM是运行所有Java程序的假想计算机，是Java程序运行环境的重要组成部分。它负责在不同操作系统平台上，将Java字节码转换成特定...
javacore-JVM性能调优实战项目
11-17
JVM性能调优是Java开发中一项关键的技术活动，它涉及到对Java虚拟机运行时环境进行监控和调整，以达到提高应用性能、减少延迟、增加吞吐量和优化资源使用的最终目的。在进行JVM性能调优时，首先要具备对Java虚拟机...
JVM 性能调优
samsung_samsung的专栏
05-30 2124
这确保了类与类之间的依赖关系一致性，避免因不同类加载器加载同一类的不同版本导致的兼容性问题，维护了程序运行的稳定性。属于应用程序自定义类，不在 JRE 核心类库中，启动类加载器和扩展类加载器均无法加载，最终由应用类加载器从 ClassPath 路径下找到对应的。全盘负责委托机制是双亲委派机制的延伸，指当一个类加载器加载某个类时，该类的所有依赖类也由同一个类加载器负责加载。，先将加载请求委托给父加载器（扩展类加载器 Extension ClassLoader），扩展类加载器再委托给启动类加载器。
java JVM 分代垃圾回收机制
谢民皆 の blog
06-12 4489
&nbsp; &nbsp; &nbsp; &nbsp; java中不同对象的生命周期是不一样的，不同周期对象课采用不同垃圾回收算法，以提高效率，根据对象活跃程度分为年轻代、年老代、持久代。JVM堆区划分为Eden、Survivor、Tenured/Old区。 年轻代 &nbsp; &nbsp; &nbsp; &nbsp; 所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉...
jvm分代回收机制及垃圾回收算法
qftyui1的博客
08-24 252
目录 GC：主要回收堆空间 分代回收理论 垃圾回收基础知识 复制算法：所有新生代使用 标记清除算法：老年代 标记整理算法：老年代 jvm常用垃圾回收器(1.8) 单线程垃圾回收器：暂停所有的用户线程，开启GC线程 多线程垃圾回收器：多个GC线程来回收 并发垃圾回收器：让业务线程和GC线程同时跑，减少了Stop the world时间 GC：主要回收堆空间 Minor GC或者Young GC：回收新生代，大概三分之一的堆空间，Eden、From、To Major GC或者Old G
JVM虚拟机（三）垃圾回收算法、分代回收、垃圾回收器种类、G1垃圾回收器
ACGkaka的博客
04-13 1819
JVM虚拟机（三）垃圾回收算法、分代回收、垃圾回收器种类、G1垃圾回收器
JVM垃圾回收的分代机制是如何实现的
soar的博客
01-08 765
转自： https://www.iteye.com/blog/pengjiaheng-524024 和 https://www.iteye.com/blog/pengjiaheng-528034 分代的垃圾回收策略：由于不同的对象的生命周期是不一样的，因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。 在Java程序运行的过程中，会产生大量的对象，其中有些对象是与...
JVM三：分代回收算法
qq_38787653的博客
11-09 460
分代的垃圾回收策略，是基于这样一个事实：不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。 年轻代: 所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。年轻代分三个区。一个Eden区，两个Survivor区(一般而言)。大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到S...
JVM从零开始（二） -垃圾回收机制以及内存分代模型
chuobenggu7592的博客
09-03 675
JVM中垃圾回收的判定标准 最终目的是将内存中无用的对象回收掉。具体的判定方法有： 引用计数法，不采用，指的是维护对象被引用的次数，次数为0则意味着是垃圾。 可达性算法-GC Roots tracing，指的是从GC Roots开始往下遍历所有引用的对象，（每个GC Root就是一个树状图）...
垃圾分代回收机制
Gavin_W_的博客
09-09 315
针对的是堆内存。 Java中的每种数据类型大小都是确定的，所以所有的内存是由Java自己进行分配，意味着内存的管理和回收也是由JVM自己进行—在Java中一旦产生内存问题导致程序员无法处理。理论上在正常情况下Java中的堆内存是足够使用的 — 当堆内存使用的负荷量（一般情况下70%）超过一定限度的时候，会启动垃圾回收器（Garbage Collector — GC）进行堆内存的回收释放 Hea...
JVM垃圾分代回收算法详解
Talk is cheap, show me the code. ---Linus Torvalds
07-24 662
注明，本文转载至:http://pengjiaheng.iteye.com/blog/524024 为什么要分代     分代的垃圾回收策略，是基于这样一个事实：不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。       在Java程序运行的过程中，会产生大量的对象，其中有些对象是与业务信息相关，比如Http请求中的Ses
JVM--分代垃圾回收机制
tongmengww的博客
11-11 441
新生代与老年代的垃圾回收机制 ——JVM新生代的区域分布新生代垃圾回收机制老年代的垃圾回收机制要点总结 新生代的区域分布 新生代的分布图如上 新生代垃圾回收机制 当伊甸园的内存不足时，如果此时再放入新的对象，则发现内存不够，会导致新生代发生一次垃圾回收，（此时进行的垃圾回收我们记为Minor GC） 此时执行的垃圾回收算法为复制算法。会将GC Root上的对象存入到幸存区（To），同时会将对象的寿...
jvm性能调优
11-10
<think>我们正在讨论JVM性能调优，根据用户的问题，他想要获取JVM性能调优的相关信息，包括方法和技巧。同时，用户提供了几个引用，但这些引用是关于JVM性能调优的概述性内容，我们需要结合这些引用以及我们对JVM调优的知识来回答。 注意：用户之前的问题是关于Java类加载机制，现在转向了JVM性能调优，因此我们要专注于调优部分。 回答结构： 1. 引言：简要介绍JVM性能调优的重要性。 2. 调优目标：明确调优的目标指标（如吞吐量、延迟、内存占用等）。 3. 调优方法：详细描述调优的常用方法和技巧（包括参数配置、监控工具、代码优化等）。 4. 实战步骤：给出一个典型的调优步骤（参考引用[4]中的步骤）。 5. 注意事项：调优中需要注意的问题。 6. 总结。 同时，根据要求，我们需要在回答末尾生成相关问题。 由于引用中提供了一些信息，我们可以适当引用，但主要依靠我们的知识库来构建详细内容。 注意：引用标记[^1]、[^2]等需要放在引用内容的后面，并且自然。 </think>### JVM性能调优方法与技巧详解 JVM性能调优是提升Java应用效率的关键，核心目标包括降低GC频率、减少STW时间、优化内存使用和提高吞吐量。以下是系统化的调优方法和实战技巧： --- #### 一、调优核心目标 1. **内存优化** - 减少堆内存碎片和Full GC次数 - 平衡新生代（Young Gen）和老年代（Old Gen）比例 - 示例参数： ```bash -Xms4g -Xmx4g # 堆内存初始值=最大值，避免动态扩容开销 -XX:NewRatio=2 # 新生代:老年代=1:2 ``` 2. **延迟优化** - 缩短GC暂停时间（STW），尤其是CMS/G1的并发阶段 - 关键指标：`GC Pause Time < 200ms`（视业务敏感度调整） 3. **吞吐量优化** - 提高应用有效工作时间占比 - 目标：`Throughput = (总运行时间 - GC时间) / 总运行时间 > 95%` [^4] --- #### 二、调优方法与技巧 ##### 1. **内存参数调优** | 参数 | 作用说明 | 调优场景 | |---------------------|----------------------------------|----------------------------| | `-XX:MaxTenuringThreshold` | 对象晋升老年代年龄阈值 | 减少过早晋升导致的Full GC | | `-XX:SurvivorRatio=8` | Eden与Survivor区比例（默认8:1:1）| 对象存活率高的应用 | | `-XX:+UseG1GC` | 启用G1垃圾收集器 | 大堆（>4GB）或低延迟需求 | **实战技巧**： - 若Minor GC频繁，增加`-Xmn`（新生代大小） - 若Full GC频繁，增大老年代或降低`-XX:MaxTenuringThreshold` ##### 2. **GC日志分析与监控** - **启用详细GC日志**： ```bash -XX:+PrintGCDetails -Xloggc:/path/to/gc.log ``` - **关键分析工具**： - `jstat -gcutil <pid> 1000`：实时监控GC各分区使用率 - `jmap -dump:format=b,file=heapdump.hprof <pid>`：生成堆转储文件 - **可视化工具**：GCViewer、MAT（Memory Analyzer）分析内存泄漏[^3] ##### 3. **垃圾收集器选择策略** | 收集器 | 适用场景 | 调优重点 | |----------------|----------------------------------|----------------------------| | **Parallel GC** | 高吞吐量应用（如批处理） | `-XX:ParallelGCThreads` | | **CMS** | 低延迟Web服务（JDK8及之前） | `-XX:CMSInitiatingOccupancyFraction` | | **G1** | 大内存+均衡吞吐/延迟（JDK9+默认） | `-XX:MaxGCPauseMillis=200` | > **案例**：某电商平台通过G1替换CMS，将99% GC暂停从500ms降至50ms[^3]。 ##### 4. **代码层优化** - **减少短命对象**：避免循环内创建临时对象 - **软/弱引用管理**：缓存使用`WeakHashMap`防止内存泄漏 - **堆外内存控制**：Netty等框架需限制`-XX:MaxDirectMemorySize` --- #### 三、调优标准化流程 [^4] 1. **基线分析**：无调优参数运行，采集GC日志和性能指标 2. **瓶颈定位**： - 高频Full GC → 检查老年代内存或对象泄漏 - 长暂停时间 → 优化GC算法或调整`MaxGCPauseMillis` 3. **参数迭代**：每次仅修改1-2个参数，对比测试 4. **监控验证**：使用APM工具（如SkyWalking）跟踪调优后效果 --- #### 四、注意事项 1. **避免过度调优**：优先优化代码和架构，JVM参数为最后手段 2. **版本差异**：JDK11+的ZGC/Shenandoah适用于超低延迟场景（暂停<10ms） 3. **监控持续性**：生产环境需持续监控`jstat`和GC日志[^2] > **调优本质**：在内存、吞吐量、延迟三者间寻找平衡点，公式表达： > $$\text{系统效率} = \frac{\text{有效计算时间}}{\text{总时间}} = 1 - \frac{\text{GC时间} + \text{其他开销}}{\text{总时间}}$$ --- ### 总结 JVM调优需结合监控数据、GC日志和业务场景迭代推进。优先通过`jstat`/堆转储定位瓶颈，再针对性调整内存分区或GC算法。对于多数应用，G1+合理堆大小配置即可满足需求，复杂场景可探索ZGC[^4]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值