最新JAVA性能调优实战教程_java性能调优实战 - osc_9z8xc00s的个人空间 - OSCHINA - 中文开源技术交流社区...

在项目压测过程中，发现系统占用，上下文切换非常频繁，在此记录下调优过程，希望对后来人有所帮助。

测试方法：模拟客户端实际操作，向服务器高并发发送数据，查看服务器的负载情况。

服务器基本配置如下

1，基本性能监控工具top

1) top 使用方式1   top

通过top命令，java应用负载极高，系统调用极高(系统调用43% ,而用户调用只有35%)，cpu的大部分资源都被系统消耗了，说明系统某部分存在极不合理的地方。

2) top 使用2；输入top后 按1，查看cpu各个核的使用情况

这个图说明了 cpu使用分布情况还不错，即程序线程池配置目前没有出现问题，如果出现单个cpu，或者几个cpu 100%，其他空闲的情况，说明线程分配不合理，无法充分利用cpu多核能力。

3) top 使用3，查看到底是什么线程在忙碌top -Hp 25994

如果你仔细观察就会发现一个有趣的现象，那就是好多线程id就像新出的人民币一样，是连着号的，一般来说，他们属于一组线程。

找到忙碌的线程，那么如何才能映射到java应用中我们自己定义的线程呢？步骤如下

a. jstack 25994 >1  将java线程dump出来

b. 将上图pid列的数字转换成16进制 比如26157   16进制为0x662d

c. more 1 。然后搜索662d

找到了，通过线程名字，可以得出，当前网络层目前比较忙碌。

注意:给线程起一个好名字非常重要，否则你刀磨的再快，命令玩儿的再溜，依然砍不到人。

2，vmstat命令 执行vmstat 1 20查看大约20次数据

从这个图上，我们能够看出至少三个方面的问题

1) 内核调用 达到50%左右，非常高

2) 上下文切换过于频繁，每秒达90000次左右

3) 调度队列线程积压  此刻的系统已经非常慢了。

查看上下文切换(pidstat 命令属于sysstat组件的内容，需要自行安装)。

pidstat -wt -p 25994  1 10 查看10次

第一列为线程id

第二列为主动上下文切换

第三列为被动上下文切换

一般来说，我们认为，线程被动上下文切换是正常的，而主动切换可能是发生了io、锁等情况。对于如此频繁的上下文切换，我们需要多dump几次线程，看看如上的线程到底在做什么，dump方法以及操作系统线程id如何映射到java线程，参见上文top -Hp命令。

查看 java线程dump文件，得到如下有效数据

应用程序频繁调用 netty 的writeAndFlush方法，从调用栈中我们看到：这个方法实际上是执行了一个系统调用，用于唤醒selectable(多重复用)阻塞线程。

netty的读写线程在频繁的与操作系统交互写数据。

综上，我们大概得到了两个结论：

1，应用频繁的调用netty的writeAndFlush方法，这可能会产生大量的系统调用.

2，netty频繁的与操作系统交互进行io操作。上文说过，io操作可能会导致线程主动切换上下文。

于是乎，两个优化思路也呼之欲出，如果writeAndFlush方法会产出大量的中断，那么netty还有没有提供其他的方法？第二个问题，io操作太过频繁，那么可不可以把消息稍微合并一下以减少io的频繁度呢？(当然这种思路需要结合实际项目，我们项目的特点是小包特别频繁)。沿着这两个思路，重新查看了netty相关部分的源码，幸运的是找到了突破口，

这两个方法天生就是一起用的，write方法可以先把数据记到内存中，等随后的flush操作把内存中所有的数据一次刷新到操作系统中。这种操作完全符合预期，即避免了系统调用，用完成了数据的 打包，美妙的是这种打包对应用而言是透明的。

调用改进策略

对于消息的发送，我们封装了统一接口，如下

这个接口被大量调用，分布于应用的各个“角落”，改变每一个调用显然是不可能的。并且，应用层是无法明确知道在何时让消息“等一会”再统一发送出去的。换句话说，就是在不改变现有调用的情况下，将这种优化“神不知鬼不觉”的添加进去。根据我们的线程分配策略，我的解决思路是在一次线程调用结束后统一发送本次调用所有消息。即将需要发送消息的Channel先存在ThreadLocal中，然后，统一操作代码片段如下

①　按线程存储 channel集合

②　设置开关，有些线程不需要做合并

③　发消息时，只需要把开启这个功能的channel存起来即可。

④　消息统一发送

有效代码不超过20行，然后我们看一下结果vmstat 1

为方便观察结果，我把上图贴下来一起对比

系统调用，上下文切换，调用队列三项指标都有显著的改善，cpu使用率提升了20%左右(观察上图的id列，下图的空闲百分比为10%左右，而上图在30%左右)。

总结：操作系统自身提供的工具，有着无与伦比的威力，再结合jdk提供的几个常用命令，如jstack(线程)、jmap(内存)、jstat(垃圾回收)等，能够帮助快速帮助我们定位问题。一般来说，操作系统监控命令能够帮助我们确定，应用到底有没有问题(诸如，cpu使用率、内存占用情况、网络、磁盘、调度队列等等)，而jdk工具能够进一步帮助我们定位问题出现在哪(线程分配、jvm堆大小配置、等等)。