最近完成了幾項比較簡單的項目, 日子有些鬆散, 終於是在996里偷了點閑暇時光, 想著來研究研究些啥吧? 一個普通的控制台日誌映入了我的眼帘(孽緣呀): (圖中使用 SpringBoot 的 log4j 來輸出日誌, logginglevel: debug, jdk版本為1.8) 造成這種現象的原因 ...
最近完成了幾項比較簡單的項目, 日子有些鬆散, 終於是在996里偷了點閑暇時光, 想著來研究研究些啥吧? 一個普通的控制台日誌映入了我的眼帘(孽緣呀):
(圖中使用 SpringBoot 的 log4j 來輸出日誌, logginglevel: debug, jdk版本為1.8)
造成這種現象的原因可能是, Mybatis在執行介面方法時, 實例化了多個Preparedstatement, 啟用了不同的NIO線程, 但是其中, 咦?! 沒錯, NIO中出了一段IO!!! (天哪!), 在查詢網路資料後, 發現:
在 JDK 1.4 中原來的 I/O 包和 NIO 已經很好地集成了。 java.io.* 已經以 NIO 為基礎重新實現了，所以現在它可以利用 NIO 的一些特性。例如， java.io.* 包中的一些類包含以塊的形式讀寫數據的方法，這使得即使在更面向流的系統中，處理速度也會更快。[引用自: IBM官方教程]
簡而言之, 就是如今的IO基本上已經與NIO集成, 在對某些單獨的讀寫操作的測試里, 也可以看出如今版本的IO速度絲毫不遜於NIO. 所以在這裡, 日誌里會有NIO同時又存在IO, 兩者互相輔佐, 當然NIO相對於IO的快, 是指, NIO更優於以下這些特性: 分散與聚集讀取, 文件鎖定, 網路非同步IO, 高併發!!!
本著一些強迫症的驅使, 我就開始了這漫長的對Java網路編程的探索之旅. 路漫漫其修遠兮, 朋友們, 一起前行! 倘若我在探索中走了哪些彎路, 歡迎評論指正!!! 在此, 本鹹魚不勝感激!!!
Java網路編程
傳輸控制協議（TCP，Transmission Control Protocol）
網路編程, 是指編寫運行在多個設備上的程式, 這些設備都是通過網路連接的.
在J2SE規範中, java.net API 封裝了低層次的通信細節, 供開發者專註於解決問題而非通信細節. 它提供了兩種常見的網路協議的支持: TCP 和 UDP .
這裡著重瞭解TCP 以及 TCP/IP
以下資料來源於度娘:
傳輸控制協議（TCP，Transmission Control Protocol）是為了在不可靠的互聯網路上提供可靠的端到端位元組流而專門設計的一個傳輸協議。應用層向TCP層發送用於網間傳輸的、用8位位元組表示的數據流，然後TCP把數據流分區成適當長度的報文段（通常受該電腦連接的網路的數據鏈路層的最大傳輸單元（MTU）的限制）。之後TCP把結果包傳給IP層，由它來通過網路將包傳送給接收端實體的TCP層。TCP為了保證不發生丟包，就給每個包一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。然後接收端實體對已成功收到的包發回一個相應的確認（ACK）；如果發送端實體在合理的往返時延 ( RTT ) 內未收到確認，那麼對應的數據包就被假設為已丟失將會被進行重傳。TCP用一個校驗和函數來檢驗數據是否有錯誤；在發送和接收時都要計算校驗和。
總結來說, 就是如下圖 ( TCP協議提供可靠的連接服務, 採用三次握手建立一個連接 ):
更加形象的表述就像是A到B家串門的情景, A先要通知B自己要去串門, 而B接受到這個消息後, 就發個消息回覆A說: "六點有空你來吧,等不急啦!" 然後A也回覆. "好嘞! 六點我就到!誒嘿嘿!!!" 最後, 六點A到了B家.
IP ( 網際網路互聯協議, Internet Protocol )
以下資料來源度娘:
IP層接收由更低層（網路介面層，例如乙太網設備驅動程式）發來的數據包，並把該數據包發送到更高層——TCP或UDP層；相反，IP層也把從TCP或UDP層接收來的數據包傳送到更低層。IP數據包是不可靠的，因為IP並沒有做任何事情來確認數據包是按順序發送的或者沒有被破壞。IP數據包中含有發送它的主機的地址（源地址）和接收它的主機的地址（目的地址）。
TCP / IP
OSI參考模型
Socket ( 套接字 )
套接字使用TCP提供了兩台電腦之間的通信機制。 客戶端程式創建一個套接字，並嘗試連接伺服器的套接字。當連接建立時，伺服器會創建一個 Socket 對象。客戶端和伺服器現在可以通過對 Socket 對象的寫入和讀取來進行通信。java.net.Socket 類代表一個套接字，並且 java.net.ServerSocket 類為伺服器程式提供了一種來監聽客戶端，並與他們建立連接的機制。
