一开始我们是通过重启服务来解决。然后我发现一个现象：就是如果使用gdb、strace、jstack -F命令来查看这些进程的运行情况，在查看之后服务会恢复正常。这样做比重启服务代价小，但随着机器增多，越来越不堪其扰。开始各种搜索，终于找到一个比较可能的问题原因：这是一个内核的Bug引起的。

      参考链接：《Linux内核漏洞将影响Haswell架构服务器》  。摘要一下：在infoq网站上，Gil Tene最近报告一个十分重要，但并不为人知Linux内核补丁，特别对采用Haswell架构的Linux系统用户和管理员应该特别关注。报告提醒Red Hat发行版的用户(包括CentOS 6.6及Scientific Linux 6.6)，即便是运行在虚拟机中的Linux，虚拟机在流行的Azure、Amazon云平台上，也可能运行在Haswell服务器上，立即更新这个补丁。这个内核漏洞的影响非常简单：在看似不可能情况下，用户进程会死锁并被挂起。即使被正确地唤醒，futex调用等待都有可能被阻止执行。如同Java里的Thread.park可能会一直阻塞等，若幸运可能会在dmesg日志中发现soft lockup消息；如果没那么幸运，将不得不花几个月的人工成本去排查问题，可能一无所获。

     可以FQ的同学可以看下：https://groups.google.com/forum/#!topic/mechanical-sympathy/QbmpZxp6C64 。 

     这个问题的处理方法是升级内核：yum install kernel -y

     后记：升级完内核后，此现象不再出现，说明升级内核是有效果的。升级完的内核版本用uname -a查看是：Linux XXX 2.6.32-642.1.1.el6.x86_64 #1 SMP Tue May 31 21:57:07 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux 。 升级之前是：Linux XXX  2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux