## 基于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進行削峰填谷；數據庫分庫；