在项目压测过程中，发现系统占用，上下文切换非常频繁，在此记录下调优过程，希望对后来人有所帮助。
测试方法：模拟客户端实际操作，向服务器高并发发送数据，查看服务器的负载情况。
服务器基本配置如下
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堆大小配置、等等）。
