java性能优化_JAVA_编程开发_程序员俱乐部

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

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

服务器基本配置如下

?

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)?调度队列线程积压??此刻的系统已经非常慢了。

3，pidstat命令?

查看上下文切换（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堆大小配置、等等）。

?

?

?

?

?

?