## 基于java NIO开发的服务端，系统使用率过高 完成开发，高高兴兴系统要上线啦！但是发现，CPU使用率过高，基本维持在80%以上。  **不选择Java原生NIO编程的原因** > 引用自《Netty权威指南 第2版》中作者对该问题的解答。 1. NIO的类库和API繁杂，使用麻烦，你需要熟练掌握Selector、ServerSocketChannel、SocketChannel、ByteBuffer等。 2. 需要具备其他的额外技能做铺垫，例如熟悉Java多线程编程。这是因为NIO编程涉及到Reactor模式，你必须对多线程和网路编程非常熟悉，才能编写出高质量的NIO程序。 3. 可靠性能力补齐，工作量和难度都非常大。例如客户端面临断连重连、网络闪断、半包读写、失败缓存、网络拥塞和异常码流的处理等问题，NIO编程的特点是功能开发相对容易，但是可靠性能力补齐的工作量和难度都非常大。 4. JDKNIO的BUG，例如臭名昭著的epollbug，它会导致Selector空轮询，最终导致CPU 100%。官方声称在JDK1.6版本的update18修复了该问题，但是直到JDK 1.7版本该问题仍旧存在，只不过该BUG发生概率降低了一些而已，它并没有得到根本性解决。 该BUG以及与该BUG相关的问题单可以参见以下链接内容。 以此来看，难道是epollbug导致的Selector空轮询导致的CPU 100%？可我们使用的JDK版本已经是JDK8的最新版本了。在这里留个小悬念，让我们用Netty实现服务端之后，我们再做一下性能上的对比。 linux系统会爆出： ``` [root@localhost ~]# Message from syslogd@localhost at May 23 23:24:20 ... kernel:NMI watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [chronyd:643] ``` 这是linux系统发生了内核软死锁（soft lockup）。主要原因之一就是：**CPU高负载时间过长**。 ### 性能瓶颈 1. java NIO CPU使用率过高； 2. Server端接收到数据之后直接进行插库，数据库的IO可能会成为瓶颈； > 遇到问题见招拆招。天下武功，没有完美的招式。 针对问题1，我们可以使用Netty方案代替； 针对问题2，结合rabbitMQ进行削峰填谷；数据库分库；