javanioaio

Ⅰ java中bio nio aio的區別和聯系

BIO是一個連接一個線程。
NIO是一個請求一個線程。
AIO是一個有效請求一個線程。
先來個例子理解一下概念，以銀行取款為例：
同步 ： 自己親自出馬持銀行卡到銀行取錢（使用同步IO時，Java自己處理IO讀寫）；
非同步 ： 委託一小弟拿銀行卡到銀行取錢，然後給你（使用非同步IO時，Java將IO讀寫委託給OS處理，需要將數據緩沖區地址和大小傳給OS(銀行卡和密碼)，OS需要支持非同步IO操作API）；
阻塞 ： ATM排隊取款，你只能等待（使用阻塞IO時，Java調用會一直阻塞到讀寫完成才返回）；
非阻塞 ： 櫃台取款，取個號，然後坐在椅子上做其它事，等號廣播會通知你辦理，沒到號你就不能去，你可以不斷問大堂經理排到了沒有，大堂經理如果說還沒到你就不能去（使用非阻塞IO時，如果不能讀寫Java調用會馬上返回，當IO事件分發器會通知可讀寫時再繼續進行讀寫，不斷循環直到讀寫完成）
Java對BIO、NIO、AIO的支持：
Java BIO ： 同步並阻塞，伺服器實現模式為一個連接一個線程，即客戶端有連接請求時伺服器端就需要啟動一個線程進行處理，如果這個連接不做任何事情會造成不必要的線程開銷，當然可以通過線程池機制改善。
Java NIO ： 同步非阻塞，伺服器實現模式為一個請求一個線程，即客戶端發送的連接請求都會注冊到多路復用器上，多路復用器輪詢到連接有I/O請求時才啟動一個線程進行處理。
Java AIO(NIO.2) ： 非同步非阻塞，伺服器實現模式為一個有效請求一個線程，客戶端的I/O請求都是由OS先完成了再通知伺服器應用去啟動線程進行處理，

Ⅱ Java學習路線是怎樣的

第一階段，Java SE基礎：

Java環境搭建、Java流程式控制制語句-for循環、switch選擇判斷、循環嵌套、數組拷貝、多維數組、final關鍵字、構造函數的調用、類的訪問許可權和路徑、面向對象高級特性、Java異常處理、Set，Map，List介面及介面實現類、Java線程、同步阻塞、JavaIO流、文件的操作，復制，讀寫，刪除等。

第二階段，JavaWeb：

MySQL安裝、管理、創建資料庫、MySQLUPDATE
查詢、Mysql高級操作、JDBC、JDBC資料庫連接操作，JDBC動態Sql處理、Servlet3.0 網頁重定向、Servlet3.0
新增的註解支持、AJAX、responseText屬性詳解等。

第三階段，Java高級框架-SSH：

Struts2異常處理、Struts2+Log4j集成、Struts2和JSON實例、Hibernate5、Hibernate集合映射、Hibernate組件映射、Spring4.0、SpringAOP+
AspectJ框架、Spring 與其它Web框架集成、Spring Hibernate支持等。

第四階段，Java高級框架-SSM：

SpringMVC、Spring MVC生成JSON數據、MyBatis、MyBatis 環境配置及入門、Mybatis set標簽、Mybatis trim標簽、Shiro、Shiro快速入門教程、Shiro Web應用等。

第五階段，SpringBoot+VUE全棧框架：

SpringBoot、全局異常處理、過濾器監聽器、EHCache緩存、SpringBoot Quartz定時任務、Vue、Vue.js 安裝、模板語法、計算屬性、事件處理器、Vue.js 自定義指令、Vue.js 路由等

第六階段，特色課程：

ActiveM環境搭建、生產者和消費者、消息持久化操作、RSA數字加密演算法、Codebar條形碼生成器、zxing二維碼生成器、HighCharts統計圖、Echarts統計圖、網路播放器ckplayer、嵌入式網路播放器，可以瀏覽器和移動端隨意使用

第七階段，互聯網框架的高級應用1：

分布式服務框架的理解，Dubbo架構設計詳解及其核心要點，框架運行原理分析、SpringData數據訪問、Lucene搜索引擎、Lucene的全文搜索伺服器介紹、索引建立方式、Solr海量數據搜索引擎、Socket網路通信、實現RMI遠程對象通訊、使用JMS消息服務、Kafka分布式消息系統、WebService與RestfulWS等

第八階段，互聯網框架的高級應用2：

Spring Security安全框架、實現Web應用安全控制、緩存應用與EhCache框架、OSCache與JBossCache框架、MyBatis與Hibernate緩存機制、NoSQL應用與SQL調優、MongoDB
NoSQL資料庫、Redis內存資料庫、實現RedisSession共享、SQL語句的優化、實現資料庫讀寫分離、WEB應用集群及性能優化、Maven項目管理工具、Web伺服器負載均衡、實現Nginx與Tomcat集群、使用LoadRunner測試工具、性能優化之內存調優、代碼優化與重構的方法等。

對java有興趣的小夥伴們，不妨先從java入門開始！B站上有很多的java教學視頻，從基礎到高級的都有，還挺不錯的，知識點講的很細致，還有完整版的學習路線圖。也可以自己去看看，下載學習試試。

Ⅲ 阻塞、非阻塞、多路復用、同步、非同步、BIO、NIO、AIO 一文搞定

關於IO會涉及到阻塞、非阻塞、多路復用、同步、非同步、BIO、NIO、AIO等幾個知識點。知識點雖然不難但平常經常容易搞混，特此Mark下，與君共勉。

阻塞IO情況下，當用戶調用 read 後，用戶線程會被阻塞，等內核數據准備好並且數據從內核緩沖區拷貝到用戶態緩存區後 read 才會返回。可以看到是阻塞的兩個部分。

非阻塞IO發出read請求後發現數據沒准備好，會繼續往下執行，此時應用程序會不斷輪詢polling內核詢問數據是否准備好，當數據沒有準備好時，內核立即返回EWOULDBLOCK錯誤。直到數據被拷貝到應用程序緩沖區，read請求才獲取到結果。並且你要注意！這里最後一次 read 調用獲取數據的過程，是一個同步的過程，是需要等待的過程。這里的同步指的是 內核態的數據拷貝到用戶程序的緩存區這個過程 。

非阻塞情況下無可用數據時，應用程序每次輪詢內核看數據是否准備好了也耗費CPU，能否不讓它輪詢，當內核緩沖區數據准備好了，以事件通知當機制告知應用進程數據准備好了呢？應用進程在沒有收到數據准備好的事件通知信號時可以忙寫其他的工作。此時 IO多路復用 就派上用場了。

IO多路復用中文比較讓人頭大，IO多路復用的原文叫 I/O multiplexing，這里的 multiplexing 指的其實是在單個線程通過記錄跟蹤每一個Sock(I/O流)的狀態來同時管理多個I/O流. 發明它的目的是盡量多的提高伺服器的吞吐能力。實現一個線程監控多個IO請求，哪個IO有請求就把數據從內核拷貝到進程緩沖區，拷貝期間是阻塞的！現在已經可以通過採用mmap地址映射的方法，達到內存共享效果，避免真復制，提高效率。

像 select、poll、epoll 都是I/O多路復用的具體的實現。

select是第一版IO復用，提出後暴漏了很多問題。

poll 修復了 select 的很多問題。

但是poll仍然不是線程安全的， 這就意味著不管伺服器有多強悍，你也只能在一個線程裡面處理一組 I/O 流。你當然可以拿多進程來配合了，不過然後你就有了多進程的各種問題。

epoll 可以說是 I/O 多路復用最新的一個實現，epoll 修復了poll 和select絕大部分問題， 比如：

橫軸 Dead connections 是鏈接數的意思，叫這個名字只是它的測試工具叫deadcon。縱軸是每秒處理請求的數量，可看到epoll每秒處理請求的數量基本不會隨著鏈接變多而下降的。poll 和/dev/poll 就很慘了。但 epoll 有個致命的缺點是只有 linux 支持。

比如平常Nginx為何可以支持4W的QPS是因為它會使用目標平台上面最高效的I/O多路復用模型。

然後你會發現上面的提到過的操作都不是真正的非同步，因為兩個階段總要等待會兒！而真正的非同步 I/O 是內核數據准備好和數據從內核態拷貝到用戶態這兩個過程都不用等待。

很慶幸，Linux給我們准備了 aio_read 跟 aio_write 函數實現真實的非同步，當用戶發起aio_read請求後就會自動返回。內核會自動將數據從內核緩沖區拷貝到用戶進程空間，應用進程啥都不用管。

我強力推薦C++後端開發免費學習地址：C/C++Linux伺服器開發/後台架構師【零聲教育】-學習視頻教程-騰訊課堂

同步跟非同步的區別在於 數據從內核空間拷貝到用戶空間是否由用戶線程完成 ，這里又分為同步阻塞跟同步非阻塞兩種。

我們以同步非阻塞為例，如下可看到，在將數據從內核拷貝到用戶空間這一過程，是由用戶線程阻塞完成的。

可發現，用戶在調用之後會立即返回，由內核完成數據的拷貝工作，並通知用戶線程，進行回調。

在Java中，我們使用socket進行網路通信，IO主要有三種模式，主要看 內核支持 哪些。

同步阻塞IO ，每個客戶端的Socket連接請求，服務端都會對應有個處理線程與之對應，對於沒有分配到處理線程的連接就會被阻塞或者拒絕。相當於是 一個連接一個線程 。

BIO特點 ：

常量：

主類：

服務端監聽線程：

服務端處理線程：

客戶端：

同步非阻塞IO之NIO ：伺服器端保存一個Socket連接列表，然後對這個列表進行輪詢，如果發現某個Socket埠上有數據可讀時說明讀就緒，則調用該socket連接的相應讀操作。如果發現某個 Socket埠上有數據可寫時說明寫就緒，則調用該socket連接的相應寫操作。如果某個埠的Socket連接已經中斷，則調用相應的析構方法關閉該埠。這樣能充分利用伺服器資源，效率得到了很大提高，在進行IO操作請求時候再用個線程去處理，是 一個請求一個線程 。Java中使用Selector、Channel、Buffer來實現上述效果。

每個線程中包含一個 Selector 對象，它相當於一個通道管理器，可以實現在一個線程中處理多個通道的目的，減少線程的創建數量。遠程連接對應一個channel，數據的讀寫通過buffer均在同一個 channel 中完成，並且數據的讀寫是非阻塞的。通道創建後需要注冊在 selector 中，同時需要為該通道注冊感興趣事件（客戶端連接服務端事件、服務端接收客戶端連接事件、讀事件、寫事件）， selector 線程需要採用 輪訓 的方式調用 selector 的 select 函數，直到所有注冊通道中有興趣的事件發生，則返回，否則一直阻塞。而後循環處理所有就緒的感興趣事件。以上步驟解決BIO的兩個瓶頸：

下面對以下三個概念做一個簡單介紹，Java NIO由以下三個核心部分組成：

channel和buffer有好幾種類型。下面是Java NIO中的一些主要channel的實現：

正如你所看到的，這些通道涵蓋了UDP和TCP網路IO，以及文件IO。以下是Java NIO里關鍵的buffer實現：

在微服務階段，一個請求可能涉及到多個不同服務之間的跨伺服器調用，如果你想實現高性能的PRC框架來進行數據傳輸，那就可以基於Java NIO做個支持長連接、自定義協議、高並發的框架，比如Netty。Netty本身就是一個基於NIO的網路框架， 封裝了Java NIO那些復雜的底層細節，給你提供簡單好用的抽象概念來編程。比如Dubbo底層就是用的Netty。

AIO是非同步非阻塞IO，相比NIO更進一步，進程讀取數據時只負責發送跟接收指令，數據的准備工作完全由操作系統來處理。

推薦一個零聲教育C/C++後台開發的免費公開課程，個人覺得老師講得不錯，分享給大家：C/C++後台開發高級架構師，內容包括Linux，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒體，CDN，P2P，K8S，Docker，TCP/IP，協程，DPDK等技術內容，C/C++Linux伺服器開發/後台架構師【零聲教育】-學習視頻教程-騰訊課堂 立即學習

原文：阻塞、非阻塞、多路復用、同步、非同步、BIO、NIO、AIO 一鍋端

Ⅳ JAVA NIO 和 AIO 的區別

Java NIO ： 同步非阻塞，伺服器實現模式為一個請求一個線程，即客戶端發送的連接請求都會注冊到多路復用器上，多路復用器輪詢到連接有I/O請求時才啟動一個線程進行處理。
Java AIO(NIO.2) ： 非同步非阻塞，伺服器實現模式為一個有效請求一個線程，客戶端的I/O請求都是由OS先完成了再通知伺服器應用去啟動線程進行處理，

NIO方式適用於連接數目多且連接比較短（輕操作）的架構，比如聊天伺服器，並發局限於應用中，編程比較復雜，JDK1.4開始支持。
AIO方式使用於連接數目多且連接比較長（重操作）的架構，比如相冊伺服器，充分調用OS參與並發操作，編程比較復雜，JDK7開始支持

I/O屬於底層操作，需要操作系統支持，並發也需要操作系統的支持，所以性能方面不同操作系統差異會比較明顯。另外NIO的非阻塞，需要一直輪詢，也是一個比較耗資源的。所以出現AIO

Ⅳ java udp 有必要用NIO嗎AIO支持UDP嗎

這得看你的程序具體的業務量了。

從性能上來說NIO是比較合適的。AIO比較符合大吞吐量的網路程序。

Ⅵ 北大青鳥java培訓：Java開發伺服器的線程怎麼處理

在進行伺服器處理的過程中，需要保證數據的正確處理，那麼最重要的就是使用不同的數據處理模式進行運算。
在整個過程中，可能很多人對伺服器的知識並不了困慧解，那麼應該如何進行Java開發伺服器的線程處理呢，關於線程處理有哪些知識？下面廣西北大青鳥為大家介紹關鍵伺服器線程處理的簡單知識。
1、BIO線程模型在JDK1.4中引入JavaNIO之前，所有基於Java的Socket通信都使用了同步阻塞模式（BIO）。
這種請求-響應通信模型簡化了上簡好層的應用程序開發上，但在具有性能和可靠性的情況下，存在一個巨大的瓶頸。
在一段時間裡面，大型應用程序伺服器主要是用C或C++開發的，因為它們可以直接使用操作系統提供的非同步I/O或AIO功能。
當流量增加且響應時間延遲增加時，JavaBIO開發的伺服器軟體只能通過硬體的不斷擴展來滿足並發性和低延遲的情況，這極大地增加了企業的成本和群集大小。
系統的不斷擴展，系統的可維護性也面臨著巨大的挑戰，只能通過購買性能更高的硬體伺服器來解決問題，這將導致惡性循環的產生。
2、非同步非阻塞線程模型從JDK1.0到JDK1.3，Java的I/O類庫非常原始。
UNIX網路編程中的許多概念或介面未反映在I/O類庫中，例如Pipe、Channel、Buffer和Selector等。
在發布JDK1.4的時候，NIO正式發布JDK作為JSR-51。
並且它還添加了一個java.nio包，為非同步I/O開發提供了許多API和庫。
3、RPC性能三原則影響RPC的性能主要有三大元素，其中主要為I/O模型、協議及線程。
I/O模型：使用什麼樣的通道傳遞給另一方，BIO，NIO或AIO發送數據，IO模型在很大程度上能夠決定框架的性能。
協議：應該使用什麼樣的通信協議，Rest+JSON或基於TCP的專用二進制協議。
參加電腦培訓的過程中發現，協議的選擇不同，性能模型也不同。
內部專用二進制協議的性汪咐答能通常可以比公共協議更好地設計。
線程：如何讀取數據報？在執行讀取後的編解碼器的哪個線程中，如何分發編碼消息，通信線程模型是不同的，並且對性能的影響也非常大。

Ⅶ JAVA 遠程 調用的幾種實現方式簡析 詳細�0�3

基本原理 要實現網路機器間的通訊，首先得來看看計算機系統網路通信的基本原理，在底層層面去看，網路通信需要做的就是將流從一台計算機傳輸到另外一台計算機，基於傳輸協議和網路 IO 來實現，其中傳輸協議比較出名的有 http、tcp、 udp 等等，http、tcp、udp 都是在基於Socket 概念上為某類應用場景而擴展出的傳輸協議，網路IO，主要有bio、nio、aio 三種方式，所有的分布式應用通訊都基於這個原理而實現，只是為了應用的易用，各種語言通常都會提供一些更為貼近應用易用的應用層協議。 應用級協議 遠程服務通訊，需要達到的目標是在一台計算機發起請求，另外一台機器在接收到請求後進行相應的處理並將結果返回給請求端，這其中又會有諸如 onewayrequest、同步請求、非同步請求等等請求方式，按照網路通信原理，需要實現這個需要做的就是將請求轉換成流，通過傳輸協議傳輸至遠端，遠端計算機在接收到請求的流後進行處理，處理完畢後將結果轉化為流，並通過傳輸協議返回給調用端。原理是這樣的，但為了應用的方便，業界推出了很多基於此原理之上的應用級的協議，使得大家可以不用去直接操作這么底層的東西，通常應用級的遠程通信協議會提供: 1.為了避免直接做流操作這么麻煩，提供一種更加易用或貼合語言的標准傳輸格式;2.網路通信機制的實現，就是替你完成了將傳輸格式轉化為流，通過某種傳輸協議傳輸至遠端計算機，遠端計算機在接收到流後轉化為傳輸格式，並進行存儲或以某種方式通知遠端計算機。 所以在學習應用級的遠程通信協議時，我們可以帶著這幾個問題進行學習: 1.傳輸的標准格式是什麼?2.怎麼樣將請求轉化為傳輸的流?3.怎麼接收和處理流?4.傳輸協議是? 不過應用級的遠程通信協議並不會在傳輸協議上做什麼多大的改進，主要是在流操作方面，讓應用層生成流和處理流的這個過程更加的貼合所使用的語言或標准，至於傳輸協議則通常都是可選的，在java 領域中知名的有:RMI、 XML-RPC、Binary-RPC、SOAP、CORBA、JMS，來具體的看看這些遠程通信的應用級協議: RMIRMI 是個典型的為java 定製的遠程通信協議，我們都知道，在 singlevm 中，我們可以通過直接調用javaobjectinstance 來實現通信，那麼在遠程通信時，如果也能按照這種方式當然是最好了，這種遠程通信的機製成為RPC(RemoteProcereCall)，RMI 正是朝著這個目標而誕生的。 來看下基於RMI 的一次完整的遠程通信過程的原理: 1.客戶端發起請求，請求轉交至RMI 客戶端的stub 類;2.stub 類將請求的介面、方法、參數等信息進行序列化;3.基於socket 將序列化後的流傳輸至伺服器端;4.伺服器端接收到流後轉發至相應的skelton 類;5.skelton 類將請求的信息反序列化後調用實際的處理類;6.處理類處理完畢後將結果返回給 skelton 類;7.Skelton 類將結果序列化，通過socket 將流傳送給客戶端的 stub;8.stub 在接收到流後反序列化，將反序列化後的JavaObject 返回給調用者。 根據原理來回答下之前學習應用級協議帶著的幾個問題: 1.傳輸的標准格式是什麼?是JavaObjectStream。2.怎麼樣將請求轉化為傳輸的流?基於Java 串列化機制將請求的javaobject 信息轉化為流。3.怎麼接收和處理流?根據採用的協議啟動相應的監聽埠，當有流進入後基於Java 串列化機制將流進行反序列化，並根據RMI 協議獲取到相應的處理對象信息，進行調用並處理，處理完畢後的結果同樣基於java 串列化機制進行返回。4.傳輸協議是?Socket。 XML-RPCXML-RPC 也是一種和RMI 類似的遠程調用的協議，它和RMI 的不同之處在於它以標準的 xml 格式來定義請求的信息(請求的對象、方法、參數等)，這樣的好處是什麼呢，就是在跨語言通訊的時候也可以使用。 來看下XML-RPC 協議的一次遠程通信過程: 1.客戶端發起請求，按照XML-RPC 協議將請求信息進行填充;2.填充完畢後將xml 轉化為流，通過傳輸協議進行傳輸;3.接收到在接收到流後轉換為xml，按照XML-RPC 協議獲取請求的信息並進行處理;4.處理完畢後將結果按照XML- RPC 協議寫入xml 中並返回。 同樣來回答問題: 1.傳輸的標准格式是?標准格式的XML。2.怎麼樣將請求轉化為傳輸的流? 將XML 轉化為流。3.怎麼接收和處理流?通過監聽的埠獲取到請求的流，轉化為XML，並根據協議獲取請求的信息，進行處理並將結果寫入XML 中返回。4. 傳輸協議是?Http。 Binary-RPCBinary-RPC 看名字就知道和XML-RPC 是差不多的了，不同之處僅在於傳輸的標准格式由XML 轉為了二進制的格式。 同樣來回答問題: 1.傳輸的標准格式是?標准格式的二進制文件。2.怎麼樣將請求轉化為傳輸的流?將二進制格式文件轉化為流。3.怎麼接收和處理流?通過監聽的埠獲取到請求的流，轉化為二進制文件，根據協議獲取請求的信息，進行處理並將結果寫入XML 中返回。4.傳輸協議是?Http。 SOAPSOAP 原意為SimpleObjectAccessProtocol，是一個用於分布式環境的、輕量級的、基於XML 進行信息交換的通信協議，可以認為SOAP 是XMLRPC 的高級版，兩者的原理完全相同，都是http+XML，不同的僅在於兩者定義的XML 規范不同，SOAP 也是Webservice 採用的服務調用協議標准，因此在此就不多加闡述了。 (公用對象請求代理[調度]程序體系結構)，是一組用來定義"分布式對象系統"的標准，由 OMG(ObjectMenagementGroup)作為發起和標准制定單位。CORBA 的目的是定義一套協議，符合這個協議的對象可以互相交互，不論它們是用什麼樣的語言寫的，不論它們運行於什麼樣的機器和操作系統。CORBA 在我看來是個類似於SOA 的體系架構，涵蓋可選的遠程通信協議，但其本身不能列入通信協議這里來講，而且CORBA 基本淘汰，再加上對CORBA 也不怎麼懂，在此就不進行闡述了。 JMSJMS 呢，是實現java 領域遠程通信的一種手段和方法，基於JMS 實現遠程通信時和RPC 是不同的，雖然可以做到RPC 的效果，但因為不是從協議級別定義的，因此我們不認為JMS 是個RPC 協議，但它確實是個遠程通信協議，在其他的語言體系中也存在著類似JMS 的東西，可以統一的將這類機制稱為消息機制，而消息機制呢，通常是高並發、分布式領域推薦的一種通信機制，這里的主要一個問題是容錯(詳細見ErLang 論文)。 來看JMS 中的一次遠程通信的過程: 1.客戶端將請求轉化為符合JMS 規定的Message;2.通過JMSAPI 將Message 放入JMSQueue 或Topic 中;3.如為JMSQueue，則發送中相應的目標Queue 中，如為Topic，則發送給訂閱了此Topic 的JMSQueue。4.處理端則通過輪訓 JMSQueue，來獲取消息，接收到消息後根據JMS 協議來解析Message 並處理。 回答問題: 1.傳輸的標准格式是?JMS 規定的Message。2.怎麼樣將請求轉化為傳輸的流?將參數信息放入Message 中即可。3.怎麼接收和處理流?輪訓JMSQueue 來接收Message，接收到後進行處理，處理完畢後仍然是以Message 的方式放入 Queue 中發送或Multicast。4.傳輸協議是?不限。 基於JMS 也是常用的實現遠程非同步調用的方法之一。

Ⅷ Java學習路線

java的學習內容很多，涵蓋較多方面，這里大致分為幾個階段提供給你參考。
一、預科學習：
HTML5：HTML5標簽入門、HTML5表格、表單
CSS3：CSS3選擇器和簡單屬性、CSS3定位和布局、CSS3復雜選擇器和高級屬性
資料庫：mysql資料庫安裝和數據操作、約束和簡單查詢、復雜查詢、資料庫設計、oracle的安裝與數據操作、oracle與mysql的對比學習

二、JavaSE
Java語言基礎、程序邏輯：環境配置和第一個語言程序-HelloWorld 變數運算符 條件和循環 方法和數組
Java面向對象：面向對象入門 面向對象應用_管理系統類 Java常用類、String相關、演算法相關 面向對象深入（重載、this、static ）繼承（重寫、super、初始化順序） 多態（抽象類和介面、final、克隆和比較介面 設計模式、對象和類的生命周期）
API：異常、日誌 集合 集合工具類和泛型 IO JDBC基礎線程 網路編程 反射 NIO Junit
Java面向對象思想：設計模式 面向對象原則
Java底層理論：集合底層 性能監控工具 反編 JUC

三、Java web
web基礎：TOMCAT/WEB程序結構/HTTP協議 Servlet基礎入門、servlet作用域（cookie、session、ServletContext）、 Cookie和Session 、Servlet的交互/JSP原理及運用、 JavaBean/EL/JSTL/MVC思想 、JSP+Servlet+JDBC綜合練習、Session購物車案例/驗證碼/防止表單重復提交、監聽器過濾器
第三方工具包：連接池、事務、分頁、文件上傳下載、Dom4j/Log4j/Log back
JavaScript和jQuery框架技術：JS入門和DOM基礎 、DOM模型深入 、jQ基礎、 jQ操作DOM
MVC動態Web開發技術：自定義MVC框架、DAO框架、前端框架（layUI）
Web開發高級運用：tomcat server伺服器配置 、nginx使用、 jetty配置
網路編程：網路原理、HTTP協議基礎、Linux操作系統、雲服務搭建

四、SSM框架
Spring框架、SpringMVC框架、MyBatis框架：mybatis入門、 配置文件詳解和動態sql的使用、 mybatis管理關系映射和延遲載入、 查詢緩存和逆向工程 、Spring入門和集成、myBatis SpringMVC入門 、SSM集成、 Spring配置詳解 、Spring AOP、 Spring事務配置 、SpringMVC高級功能 、SpringMVC原理

五、前沿技術
高可用、高並發、高擴展：Spring Boot 、緩存 、分布式 、全文索引、 服務中間件、 myCat、 雲服務 、人臉識別 、語言識別 、JVM底層+優化

希望能夠幫到你！！！

Ⅸ java的nio和aio在linux中是如何實現的，是epoll嗎

Linux企業應用案例精解這本書，寫的不錯，舉得案例比較有代表性，綜合性挺強的，實驗過程記錄的挺清楚，不過要是都有視頻教學就更好了，以前總覺得我自己的linux水平不錯的，不過看了這本書後真是感覺我還有很多要學的。

Ⅹ java與mysql是nio還是bio

Java中的IO方式主要分為3種：BIO（同步阻塞）、NIO（同步非阻塞）和AIO（非同步非阻塞）。

BIO

同步阻塞模式。在JDK1.4以前，使用Java建立網路連接時，只能採用BIO方式，在伺服器端啟動一個ServerSocket，然後使用accept等待客戶端請求，對於每一個請求，使用一個線程來進行處理用戶請求。線程的大部分時間都在等待請求的到來和IO操作，利用率很低。而且線程的開銷比較大，數量有限，因此伺服器同時能處理的連接數也很低。

NIO

BIO模式中，是「一個Socket一個線程」；而在NIO中則是使用單個或少量的線程來輪詢Socket，當發現Socket上有請求時，才為請求分配線程。因此是「一個請求一個線程」。

具體實現就是把Socket通過Channel注冊到Selector，使用一個線程在Selector中輪詢，發現Channel有讀寫的事件，就可以分配給其他線程來處理（通常使用線程池）。

AIO

從JDK7開始支持AIO模式。通過中注冊事件回調函數來處理業務邏輯。當IO操作完成以後，回調函數會被調用。如果傳入AsynchronousChannelGroup，可以綁定線程池來處理事件。

關於JDK的實現，Windows平台基於IOCP實現AIO，Linux只有eppoll模擬實現了AIO。

附：關於IO經常提到Reactor/ Proactor模式。

這兩個模式中都有兩個角色：事件多路分離器(Event Demultiplexer)和事件處理器(Event Handler)。分離器負責對監聽IO事件，並通知處理器；處理器負責對IO內容進行處理，完成對應的業務。

二者的差異，以讀操作為例（寫操作類似）。

Reactor中實現讀：

1.注冊讀就緒事件和相應的事件處理器。

2.事件分離器等待事件。

3.事件到來，激活分離器，分離器調用對應的處理器。

4.處理器完成IO讀操作，處理讀到的數據，注冊新的事件，然後返還控制權。

Proactor中實現讀：

1.注冊讀完成事件和相應的事件處理器（包括緩沖區地址）。

2.事件分離器等待操作完成事件的同時，操作系統利用並行的內核線程執行實際的讀操作，並將結果數據存入用戶自定義緩沖區，最後通知事件分離器讀操作完成。

3.事件分離器呼喚處理器。

4.事件處理器處理用戶自定義緩沖區中的數據，然後啟動一個新的非同步操作，並將控制權返回事件分離器。

由此可見，兩者的主要區別：Reactor中，由用戶線程（事件處理器所在線程）完成IO的讀寫操作；而在Proactor中，是由操作系統完成IO讀寫操作後，再通知事件處理器，用戶線程只完成對數據的業務邏輯處理部分。

更多問題可以問遠標教育中心的技術咨詢。