关键词：
玩过性能优化的朋友都清楚，性能优化的关键并不在于怎么进行优化，而在于怎么找到当前系统的性能瓶颈。性能优化分为好几个层次，比如系统层次、算法层次、代码层次...JVM 的性能优化被认为是底层优化，门槛较高，精通这种技能的人比较少。笔者呆过几家技术力量不算弱的公司，每个公司内部真正能够进行 JVM 性能调优的人寥寥无几、甚至没有。如是乎，能够有效通过 JVM 调优提升系统性能的人往往被人们冠以"大牛"、"大师"之类的称呼。
其实 JVM 本身给我们提供了很多强大而有效的监控进程、分析定位瓶颈的工具，比如 JConsole、JMap、JStack、JStat 等等。使用这些命令，再结合 Linux 自身提供的一些强大的进程、线程命令，能够快速定位系统瓶颈。本文以一次使用这些工具准确定位到某系统瓶颈的实战经验为例，希望能为大家掌握 JVM 调优这项技能起到一些借鉴作用。
本文背景：
- Linux：RedHat 6.1
- Weblogic：11g
- JRokit：R28.2.4
- JDK：1.6.0_45
1. LoadRunner 压测结果
该系统其实早已跑在生产上好多年，虽然没有做过压力测试，但稳定性还是可以的。公司进行架构调整，有一些新系统将对接该系统。公司领导担心对接后该系统的并发性能问题，于是开始对该系统进行并发压力测试。50 个用户并发压十几个小时，TRT 在 20 左右，TPS 在 2.5 左右。领导对这个结果不满意，要求进行优化。但这是个老系统，开发在之前明显已经对其代码做过很多优化，如今面对这种状况也束手无策。
2. Oracle 的 awr 报告分析
有句老话，优化来优化去，系统的性能瓶颈还是会在数据库上面。在这里我们首先想到的也是数据库的问题。并发压测的时候 Spotlight 查看数据库服务器各项性能指标，很清闲。
分析 awr 报告，结果显示也是很清闲。
并发压测的时候去相关数据表执行一些 sql 的速度很快也证明着问题不在 Oracle 这边。
3. Weblogic 服务器的性能指标
使用 Spotlight 查看并发压测时的 Weblogic 所在的 Linux 服务器，除了 CPU 之外其它各项指标显示，Linux 也很清闲。虽然 CPU 利用率始终在 200% 左右徘徊，但这对于 16 核的系统来讲也算是正常的吧？
4. JStack 报告分析
事情到了这里，大家已经想到了线程死锁、等待的问题了。没错，JStack 隆重登场。JStack 能够看到当前 Java 进程中每个线程的当前状态、调用栈、锁住或等待去锁定的资源，而且很强悍的是它还能直接报告是否有线程死锁，可谓解决线程问题的不二之选。
$ /opt/jdk1.6.0_45/bin/jstack -l 10495 > ~/10495jstack.txt
JRokit 堆栈的拉取，可以直接用 JDK 的 JStack，10495 是 Weblogic 服务的进程 ID。注意一定要用该进程的启动用户去拉，否则会报 Unable to open socket file: target process not responding or HotSpot VM not loaded 错误。
JStack 拉取的文件信息基本分为以下几个部分：
- 该拉取快照的服务器时间
- JVM 版本
- 以线程 ID(即 tid)升序依次列出当前进程中每个线程的调用栈
- 死锁(如果有的话)
- 阻塞锁链
- 打开的锁链
- 监视器解锁情况跟踪
4.1. TLA 空间的调整
多次拉取 JStack，发现很多线程处于这个状态：at jrockit/vm/Allocator.getNewTla(JJ)V(Native Method)
at jrockit/vm/Allocator.allocObjectOrArray(Allocator.java:354)[optimized]
at java/util/HashMap.resize(HashMap.java:564)[inlined]
at java/util/LinkedHashMap.addEntry(LinkedHashMap.java:414)[optimized]
at java/util/HashMap.put(HashMap.java:477)[optimized]
由此怀疑出现上述堆栈的原因可能是 TLA 空间不足引起。TLA 是 thread local area 的缩写，是每个线程私有的空间，所以在多线程环境下 TLA 带来的性能提升是显而易见的。如果大部分线程的需要分配的对象都较大，可以考虑提高 TLA 空间，因为这样更大的对象可以在 TLA 中进行分配，这样就不用担心和其它线程的同步问题了。但这个也不可以调的太大，否则也会带来一些问题，比如会带来更多内存碎片、更加频繁的垃圾搜集。
TLA 默认最小大小 2 KB，默认首选大小 16 KB - 256 KB (取决于新生代分区大小)。这里我们调整 TLA 空间大小为最小 32 KB，首选 1024 KB，JVM 启动参数中加入：
-XXtlaSize:min=32k,preferred=1024k
5. JStat 结合 GC 日志报告分析
第 4 步参数生效之后继续压测，TLA 频繁申请是降下来了，但 TRT 仍旧是 20，TPS 依旧 2.5。别灰心，改一个地方就立竿见影，胜利似乎来得太快了点。现在怀疑是服务堆内存太小，查看一下果然。服务器物理内存 32 GB，Weblogic 进程只分到了 6 GB。怎么查看？至少有四种办法：
5.1. ps 命令
$ ps -ef | grep javadefonds 29874 29819 2 Sep03 ? 09:03:17 /opt/jrockit-jdk1.6.0_33/bin/jav a -jrockit -Xms6000m -Xmx6000m -Dweblogic.Name=AdminServer -Djava.security.policy=
5.2. Weblogic 控制台
登录 Weblogic 管理控制台 -> 环境 -> 服务器，选择该服务器实例 -> 监视 -> 性能 -> 当前堆大小。这个页面还能看到进程已运行时间，启动以来发生的 GC 次数，可以折算出 GC 的频率，为本次性能瓶颈 - GC 过于频繁提供有力的佐证。
5.3. GC 日志报告
开启 JRokit GC 日志报告只需在 Java 进程启动参数里加入-Xverbose:memory -Xverboselog:verboseText.txt
GC 日志将会被输出到 verboseText.txt 文件，这个文件一般会生成在启动的 Weblogic 域目录下。如果找不着也可以用 find 命令去搜：
$ find /appserver/ -name verboseText.txt
/appserver/Oracle/Middleware/user_projects/domains/defonds_domain/verboseText.txt
GC log 拿到后，第 3 行中的 maximal heap size 即为该进程分配到的最大堆大小：
[INFO ][memory ] Heap size: 10485760KB, maximal heap size: 10485760KB, nursery size: 5242880KB.
下面还有进程启动以后较为详细的每次 GC 的信息：
[INFO ][memory ] [YC#2547] 340.828-340.845: YC 10444109KB->10417908KB (10485760KB), 0.018 s, sum of pauses 17.294 ms, longest pause 17.294 ms.
[INFO ][memory ] [YC#2548] 340.852-340.871: YC 10450332KB->10434521KB (10485760KB), 0.019 s, sum of pauses 18.779 ms, longest pause 18.779 ms.
[INFO ][memory ] [YC#2549] 340.878-340.895: YC 10476739KB->10485760KB (10485760KB), 0.017 s, sum of pauses 16.520 ms, longest pause 16.520 ms.
[INFO ][memory ] [OC#614] 340.895-341.126: OC 10485760KB->10413562KB (10485760KB), 0.231 s, sum of pauses 206.458 ms, longest pause 206.458 ms.
第一行表示该进程启动后的第 340.828 秒 - 340.845 秒期间进行了一次 young gc，该次 GC 持续了 17.294 ms，将整个已用掉的堆内存由 10444109 KB 降低到 10417908 KB。
第三行同样是一次 young gc，但该次 GC 后已用堆内存反而上升到了 10485760 KB，也就是达到最大堆内存，于是该次 young gc 结束的同时触发 full gc。
第四行是一次 old gc (即 full gc)，将已用堆内存由 10485760 KB 降到了 10413562 KB，耗时 206.458 ms。
这些日志同样能够指出当前压力下的 GC 的频率，为本次性能瓶颈 - GC 过于频繁提供有力的佐证。
5.4. JStat 报告
跟 JStack 的拉取一样，可以直接用 JDK 的 JStat 去拉取 JRokit 的 GC 信息：$ /opt/jdk1.6.0_45/bin/jstat -J-Djstat.showUnsupported=true -snap 10495 > ~/10495jstat.txt
注意这个信息是一个快照，这是跟 GC 日志报告不同的地方。
jrockit.gc.latest.heapSize=10737418240
jrockit.gc.latest.nurserySize=23100384
上述是当前已用碓大小和新生代分区大小。多拉几次即可估算出各自分配的大小。
5.5. 内存分配
根据 5.1 - 5.4 我们得出当前服务器分配堆内存太小的结论，根据 5.3 GC 日志报告和 5.4. JStat 报告可以得出新生代分区太小的结论。于是我们调整它们的大小，结合 4.1 TLA 调整的结论，JVM 启动参数增加以下：
-Xms10240m -Xmx10240m -Xns:1024m -XXtlaSize:min=32k,preferred=1024k
再次压测，TRT 降到了 2.5，TPS 上升到 20。
6. 性能瓶颈的定位
很明显，上述 JVM 调整没有从根本上解决性能问题，我们还没有真正定位到系统性能瓶颈。6.1. 性能线程的定位
6.1.1. 性能进程的获取
使用 TOP 命令拿到最耗 CPU 的那个进程：
进程 ID 为 10495 的那个进程一直在占用很高的 CPU。
6.1.2. 性能线程的获取
现在我们来找到这个进程中占用 CPU 较高的那些线程：$ ps p 10495 -L -o pcpu,pid,tid,time,tname,cmd > ~/10495ps.txt
多次拉这个快照，我们找到了 tid 为 10499、 10500、 10501、 10502 等线程一直在占用着很高的 CPU：
拉 JStack 快照看看都是一些什么线程：
$ /opt/jdk1.6.0_45/bin/jstack -l 10495 > ~/10495jstack.txt
相关部分结果如下：
"(GC Worker Thread 1)" id=? idx=0x10 tid= 10499 prio=5 alive, daemon
at pthread_cond_wait@@GLIBC_2.3.2+202(:0)@0x3708c0b44a
at eventTimedWaitNoTransitionImpl+71(event.c:90)@0x7fac47be8528
at eventTimedWaitNoTransition+66(event.c:72)@0x7fac47be8593
at mmGCWorkerThread+137(gcthreads.c:809)@0x7fac47c0774a
at thread_stub+170(lifecycle.c:808)@0x7fac47cc15bb
at start_thread+208(:0)@0x3708c077e1
Locked ownable synchronizers:
- None
"(GC Worker Thread 2)" id=? idx=0x14 tid= 10500 prio=5 alive, daemon
at pthread_cond_wait@@GLIBC_2.3.2+202(:0)@0x3708c0b44a
at eventTimedWaitNoTransitionImpl+71(event.c:90)@0x7fac47be8528
at eventTimedWaitNoTransition+66(event.c:72)@0x7fac47be8593
at mmGCWorkerThread+137(gcthreads.c:809)@0x7fac47c0774a
at thread_stub+170(lifecycle.c:808)@0x7fac47cc15bb
at start_thread+208(:0)@0x3708c077e1
Locked ownable synchronizers:
- None
"(GC Worker Thread 3)" id=? idx=0x18 tid= 10501 prio=5 alive, daemon
at pthread_cond_wait@@GLIBC_2.3.2+202(:0)@0x3708c0b44a
at eventTimedWaitNoTransitionImpl+71(event.c:90)@0x7fac47be8528
at eventTimedWaitNoTransition+66(event.c:72)@0x7fac47be8593
at mmGCWorkerThread+137(gcthreads.c:809)@0x7fac47c0774a
at thread_stub+170(lifecycle.c:808)@0x7fac47cc15bb
at start_thread+208(:0)@0x3708c077e1
Locked ownable synchronizers:
- None
"(GC Worker Thread 4)" id=? idx=0x1c tid= 10502 prio=5 alive, daemon
at pthread_cond_wait@@GLIBC_2.3.2+202(:0)@0x3708c0b44a
at eventTimedWaitNoTransitionImpl+71(event.c:90)@0x7fac47be8528
at eventTimedWaitNoTransition+66(event.c:72)@0x7fac47be8593
at mmGCWorkerThread+137(gcthreads.c:809)@0x7fac47c0774a
at thread_stub+170(lifecycle.c:808)@0x7fac47cc15bb
at start_thread+208(:0)@0x3708c077e1
Locked ownable synchronizers:
- None
6.2. 找到性能瓶颈
事情到了这里，已经不难得出当前系统瓶颈就是频繁 GC。为何会如此频繁 GC 呢？继续看 JStack，发现这两个互相矛盾的现象：
一方面 GC Worker 线程在拼命 GC，但是 GC 前后效果不明显，已用堆内存始终降不下来；
另一方面大量 ExecuteThread 业务处理线程处于 alloc_enqueue_allocation_and_wait_for_gc 的 native_blocked 阻塞状态。
此外，停止压测以后，查看已用堆内存大小，也就几百兆，不到分配堆内存的 1/10。
这说明了什么呢？这说明了我们应用里没有内存泄漏、静态对象不是太多、有大量的业务线程在频繁创建一些生命周期很长的临时对象。
很明显还是代码里有问题。那么这些对象来自哪里？如何在海量业务代码里边准确定位这些性能代码？也就是说如何利用 JVM 调优驱动代码层面的调优？请参考博客《 JVM 性能调优实战之：使用阿里开源工具 TProfiler 在海量业务代码中精确定位性能代码》，使用 TProfiler 我们成功找到了代码里边导致 JVM 频繁 GC 的元凶，并最终解决掉了这个性能瓶颈，将 TRT 降到了 0.5，TPS 提升至 100 +。
参考资料
day820.抢购活动性能瓶颈调优-java性能调优实战(代码片段)
抢购活动性能瓶颈调优Hi，我是阿昌，今天学习记录的是关于抢购活动性能瓶颈调优。每年的双十一都是很多研发部门最头痛的节日，由于这个节日比较特殊，公司一般都会准备大量的抢购活动，相应的瞬时高... 查看详情
jvm性能调优
JVM技术图谱 性能调优性能调优包含多个层次，比如：架构调优、代码调优、JVM调优、数据库调优、操作系统调优等。架构调优和代码调优是JVM调优的基础，其中架构调优是对系统影响最大的。性能调优基本上按照以... 查看详情
深入理解jvm——jvm性能调优实战
如何在高性能服务器上进行JVM调优；以便充分利用高性能服务器的硬件资源，有两种JVM调优方案。一、 采用64位操作系统，并为JVM分配大内存分析：如果JVM中堆内存太小，那么就会频繁地发生垃圾... 查看详情
性能调优--哪些计算机资源有可能成为系统的性能瓶颈？
...，导致其他资源无法争夺到CPU而响应缓慢，从而带来系统性能问题。比如：代码递归导致的无限循环，正则表达式引起的回溯，JVM频繁的FULLGC，以及多线程编程造成的大量上下文切换等等，这些都有可能导致CPU资源繁忙。内存&nb... 查看详情
day800.jvm内存分配优化-java性能调优实战(代码片段)
...调优都是有目标性的，JVM内存分配调优也一样。没有性能问题的时候，自然不会随意改 查看详情
day800.jvm内存分配优化-java性能调优实战(代码片段)
...调优都是有目标性的，JVM内存分配调优也一样。没有性能问题的时候，自然不会随意改 查看详情
informatica
安装性能调优 性能瓶颈 性能瓶颈概览 性能瓶颈之Target 性能瓶颈之Source 性能瓶颈之Mapping 性能瓶颈之Session 性能瓶颈之System 性能调优 性能调优之Target 性... 查看详情
day776.如何制定性能调优策略-java性能调优实战(代码片段)
如何制定性能调优策略Hi，我是阿昌，今天学习记录的是关于如何制定性能调优策略。面对日渐复杂的系统，制定合理的性能测试，可以提前发现性能瓶颈，然后有针对性地制定调优策略。总结一下就是“测试... 查看详情
jvm性能调优
JVM技术图谱 性能调优性能调优包含多个层次，比如：架构调优、代码调优、JVM调优、数据库调优、操作系统调优等。架构调优和代码调优是JVM调优的基础，其中架构调优是对系统影响最大的。性能调优基本上按照以... 查看详情
ifeve.com南方《jvm性能调优实战之：使用阿里开源工具tprofiler在海量业务代码中精确定位性能代码》
https://blog.csdn.net/defonds/article/details/52598018多次拉取JStack，发现很多线程处于这个状态： atjrockit/vm/Allocator.getNewTla(JJ)V(NativeMethod) atjrockit/vm/Allocator.allocObjectOrArray(Alloc 查看详情
性能调优之jvm调优gc性能指标及调优实战
...JVM运行环境解决JVM运行中出现的各种问题，比如OOMGC性能指标吞吐量:工作线程运行时间占比总运行时间之比用户程序执行时间/（用户程序执行时间+垃圾回收时间）单位时间内，STW的时间最短（发生2次STW... 查看详情
zabbix实战之运维篇zabbix监控平台的简单性能调优
【Zabbix实战之运维篇】Zabbix监控平台的简单性能调优一、Zabbix性能优化介绍1.造成Zabbix服务器变慢原因2.Zabbix性能调优的方法二、检查Zabbix服务器的资源占用情况1.检查Zabbix各组件容器的资源占用情况2.查看Zabbix系统的当前负载状... 查看详情
jvm性能调优实战-61常用的jvm调优网站
文章目录线程Dump日志分析堆Dump可视化分析GC日志分析AlibabaArthasAliabbajvmGeneratePerfMaPerfMa-XXFox（Java虚拟机参数分析）PerfMa-XSheepdog(Java线程Dump分析)PerfMa-XElephant(Java内存Dump分析)线程Dump日志分析https://fastthread.io在线的 查看详情
day783.网络通信优化之i/o模型：如何解决高并发下i/o瓶颈-java性能调优实战(代码片段)
网络通信优化之I/O模型：如何解决高并发下I/O瓶颈Hi，我是阿昌，今天学习记录的是关于网络通信优化之I/O模型：如何解决高并发下I/O瓶颈。提到JavaI/O，相信你一定不陌生。可能使用I/O操作读写文件，也可... 查看详情
性能调优一次监控数据错误的性能调优经历(代码片段)
...，qps一直卡在1w，但是从各种监控和分析并未找到性能瓶颈，最后发现竟然因为数据库cpu监控不准备误导，特此记录整个调优的过程一、源码分析回调接口源码性能分析：1次redis查询2次db操作，其中1次查询... 查看详情
性能测试常见瓶颈分析及调优方法(代码片段)
在性能测试过程中，最重要的一部分就是性能瓶颈定位与调优。而引发性能瓶颈的原因是多种多样的，在之前的博客：常见的性能测试缺陷有进行介绍。这篇博客，来聊聊性能测试过程中的一些注意事项，以及常见的一些性能缺... 查看详情
一次简单的jvm调优，性能提升了15%
...https://zhenbianshu.github.io/背景最近对负责的项目进行了一次性能优化，其中包括对JVM参数的调整，算是进行了一次简单的JVM调优，JVM参数调整之后，服务的整体性能有15%左右的提升，还算不错。先介绍一下项目的基本情况：项目是... 查看详情
高性能java计算服务的性能调优实战
...团队-ChenDongxing、LiHaoxuan、ChenJinxia随着业务的日渐复杂，性能优化俨然成为了每一位技术人的必修课。性能优化从何着手？如何从问题表象定位到性能瓶颈？如何验证优化措施是否有效？本文将介绍分享vivopush推荐项目中的性能... 查看详情