java 高效能網路編程

 java.io.*

其是最原始的的最簡的 IO 操作.
通常使用簡單. 適合於並發數量不大的情況.
其 IO 時是阻塞的狀態.
對於多SOCKET 來說可能要每SOCKET建立一個
Thread進行處理. 可想而有1000或更多的情況
下,伺服器會成什麼樣子. 伺服器都在忙於線程交換了.

java.nio.*
這是 Java 的非同步IO 處理包. Socket 一般使用
select 的機制. 就是cpu 不斷的查詢所有的SOCKET
控制代碼,有事件它就報告. 比 java.io.* 有很大的進步
不過使用起來不是特別方便. 但是網上有許多的開源
NIO 架構可以使用. apahce MINA/windy 等. 使用方
法都差不多. 封裝的很好.
但是顯然這種情況CPU的佔用率要高了.

iocp (windows), kqueue(freebsd), 或是 epoll(linux)
高效能的SOCKET.
一般的線上的網遊都使用這些技術進行網路連接的架構.

聽說 QQ Game 就是使用 epoll , 單台 Server 可以支援
萬層級的Socket 串連. 汗了.

讓人高興的是 JDK6.0 開始支援 epoll 了.
A new java.nio.channels.SelectorProvider implementation that is based
on the Linux epoll event notification facility is included.
The epoll facility is available in the Linux 2.6, and newer,
kernels. The new epoll-based SelectorProvider implementation
is more scalable than the traditional poll-based SelectorProvider
implementation when there are thousands of SelectableChannels
registered with a Selector. The new SelectorProvider implementation
 will be used by default when the 2.6 kernel is detected.
The poll-based SelectorProvider will be used when a pre-2.6 kernel is detected.

網上看到 JDK5.0 已經有 epoll的實現了.
The epoll SelectorProvider will be included in 5.0 update 9.
To enable it requires setting the system property
java.nio.channels.spi.SelectorProvider to the value
sun.nio.ch.EPollSelectorProvider

總結:

java.io.*
相當於1000個民兵都去村口等著鬼子,來一個鬼子殺一個.
個人評論:村口地方小站不開呀!

select
相當於 一遍遍的詢問“鬼子進村了嗎？”，“鬼子進村了嗎？”...
個人評論:煩呀,不幹正經事,都磨嘴皮子了.

iocp (windows), kqueue(freebsd), 或是 epoll(linux)
一個人去村口站崗,等鬼子來,鬼子來去報告.