JVM性能调优

JVM调优工具

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

 

JProfiler:商业软件,需要付费。功能强大。

 

VisualVM:JDK自带,功能强大,与JProfiler类似。推荐。

 

如何调优

观察内存释放情况、集合类检查、对象树

上面这些调优工具都提供了强大的功能,但是总的来说一般分为以下几类功能

 

堆信息查看

 

可查看堆空间大小分配(年轻代、年老代、持久代分配)

提供即时的垃圾回收功能

垃圾监控(长时间监控回收情况)

 

 

查看堆内类、对象信息查看:数量、类型等

 

 

对象引用情况查看

 

有了堆信息查看方面的功能,我们一般可以顺利解决以下问题:

  --年老代年轻代大小划分是否合理

  --内存泄漏

  --垃圾回收算法设置是否合理

 

线程监控

 

线程信息监控:系统线程数量。

线程状态监控:各个线程都处在什么样的状态下

 

 

Dump线程详细信息:查看线程内部运行情况

死锁检查

 

热点分析

 

 

 

    CPU热点:检查系统哪些方法占用的大量CPU时间

    内存热点:检查哪些对象在系统中数量最大(一定时间内存活对象和销毁对象一起统计)

 

    这两个东西对于系统优化很有帮助。我们可以根据找到的热点,有针对性的进行系统的瓶颈查找和进行系统优化,而不是漫无目的的进行所有代码的优化。

 

 

快照

    快照是系统运行到某一时刻的一个定格。在我们进行调优的时候,不可能用眼睛去跟踪所有系统变化,依赖快照功能,我们就可以进行系统两个不同运行时刻,对象(或类、线程等)的不同,以便快速找到问题

    举例说,我要检查系统进行垃圾回收以后,是否还有该收回的对象被遗漏下来的了。那么,我可以在进行垃圾回收前后,分别进行一次堆情况的快照,然后对比两次快照的对象情况。

 

内存泄漏检查

    内存泄漏是比较常见的问题,而且解决方法也比较通用,这里可以重点说一下,而线程、热点方面的问题则是具体问题具体分析了。

    内存泄漏一般可以理解为系统资源(各方面的资源,堆、栈、线程等)在错误使用的情况下,导致使用完毕的资源无法回收(或没有回收),从而导致新的资源分配请求无法完成,引起系统错误。

    内存泄漏对系统危害比较大,因为他可以直接导致系统的崩溃。

    需要区别一下,内存泄漏和系统超负荷两者是有区别的,虽然可能导致的最终结果是一样的。内存泄漏是用完的资源没有回收引起错误,而系统超负荷则是系统确实没有那么多资源可以分配了(其他的资源都在使用)。

 

 

年老代堆空间被占满

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

<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、付费专栏及课程。

余额充值