javanio源碼

① 關於使用java的java.nio.channels.FileLock，實現程序對文件的獨占讀寫的問題

用你的方法,當你鎖住文件再解鎖的時候你會發現,原來文件里的內容不見了,所以後一段讀文本的程序只能讀到一個null ,你可以參考這個http://blog.csdn.net/wangjichen_1/article/details/6205779

② sun.nio包是什麼，是java代碼么

Oracle/Sun JDK下的src.zip只帶有 java.* / javax.* 的公有API的源碼，sun.nio屬於Oracle/Sun JDK的私有API，所以沒有包含在src.zip里。
所謂公有/私有API，此處最大的區別不在於是否開放源碼，而在於是否屬於Java平台規范的一部分。
Java標准庫的公有API屬於規范的一部分，所有符合規范的JDK/JRE實現都必須提供完全一樣的Java標准庫公有API（只要API兼容即可，不要求內部實現完全一樣）。而私有部分可以每個JDK/JRE自行決定API。

從OpenJDK 7開始，Oracle JDK跟OpenJDK的Java庫的大部分源碼都是完全一致的。有需要的話請去OpenJDK看源碼

③ java 1.7 nio 監測共享文件夾

共享文件夾在哪裡？是把本地的某個文件夾設為共享文件夾 還是有個共享伺服器？前者我試了 是起作用的...後者沒試...

④ 如何引入java.nio.heapbytebuffer

heap buffer 和 direct buffer區別

在Java的NIO中，我們一般採用ByteBuffer緩沖區來傳輸數據，一般情況下我們創建Buffer對象是通過ByteBuffer的兩個靜態方法：

ByteBuffer.allocate(int capacity);
ByteBuffer.wrap(byte[] array);

查看JDK的NIO的源代碼關於這兩個部分：

/**allocate()函數的源碼**/
public static ByteBuffer allocate(int capacity) {
if (capacity < 0)
throw new IllegalArgumentException();
return new HeapByteBuffer(capacity, capacity);
}

/**wrap()函數的源碼**/
public static ByteBuffer wrap(byte[] array) {
return wrap(array, 0, array.length);
}
//
public static ByteBuffer wrap(byte[] array,
int offset, int length)
{
try {
return new HeapByteBuffer(array, offset, length);
} catch (IllegalArgumentException x) {
throw new IndexOutOfBoundsException();
}
}

我們可以很清楚的發現，這兩個方法都是實例化HeapByteBuffer來創建的ByteBuffer對象，也就是heap buffer. 其實除了heap buffer以外還有一種buffer，叫做direct buffer。我們也可以創建這一種buffer，通過ByteBuffer.allocateDirect(int capacity)方法，查看JDK源碼如下：

public static ByteBuffer allocateDirect(int capacity) {
return new DirectByteBuffer(capacity);
}

我們發現該函數調用的是DirectByteBuffer(capacity)這個類，這個類就是創建了direct buffer。

⑤ 最近看到Java一個開源的nio框架MINA。想問MINA2.0有哪些缺陷。時間問題等不及慢慢看完MINA源碼。

mina一般是嵌入伺服器中的，要是標準的C/S還是用C++寫的吧。

⑥ java.nio相關及apache的mina框架求助

你就別置頂了 這么多天了！花點時間花點時間自己也就做出來了！
不就是socket通訊嘛，網上類似 java.nio斷點續傳的沒發現的話，那其他語言的斷點續傳的多的是啊？ 原理就是 比如說客戶端讀取一段文件 1000位元組 同時建立一個記錄文件 記錄傳輸狀態
比如說 傳輸中 已完成之類的狀態
服務端接收文件，寫到一個臨時文件里，並建立一個記錄文件，記錄接收到哪兒了。
如此循環,一直到完成。 然後將這臨時文件改為目標文件名
如果通訊有中斷，客戶端再發起socket連接，第一步就是讀取記錄文件，如果有未完成的文件傳輸，就請求服務端返回服務端接收文件的位置。 客戶端就知道需要從哪兒開始讀。繼續讀 繼續發送

⑦ java io nio上傳文件哪個快

以FileInputStream類為例，該類有一個read(byte b[])方法，byte b[]是我們要存儲讀取到用戶空間的緩沖區。參看read(byte b[])方法的源碼，可知，它會在內部再調用readBytes(b, 0, b.length)方法，而且readBytes(b, 0, b.length)方法是一個native方法（即本地方法），最終通過這個本地方法來發起一次系統調用，即調用系統內核的read()方法，內核從磁碟讀取數據到內核緩沖區，這個過程由磁碟控制器通過DMA操作將數據從磁碟讀取取內核緩沖區，此過程不依賴於CPU。然後用戶進程再將數據從內核緩沖區拷貝到用戶空間緩沖區。用戶進程再從用戶空間緩沖區中讀取數據。

⑧ 誰能幫我解釋下java的NIO包中ByteBuffer類的clear(),flip(),rewind()方法的意思，這些方法有什麼作用

首先澄清一點：這三個方法都是ByteBuffer的抽象基類Buffer定義的方法，ByteBuffer只是繼承了它們。

****************************************************
其次，你要理解緩沖區的概念，就是Buffer的意義：緩沖區是特定基本類型元素的線性有限序列。除內容外，緩沖區的基本屬性還包括容量、限制和位置：

緩沖區的容量 是它所包含的元素的數量。緩沖區的容量不能為負並且不能更改。

緩沖區的限制 是第一個不應該讀取或寫入的元素的索引。緩沖區的限制不能為負，並且不能大於其容量。

緩沖區的位置 是下一個要讀取或寫入的元素的索引。緩沖區的位置不能為負，並且不能大於其限制。

任何插入或讀取都不能超出限制。

標記、位置、限制和容量值遵守以下不變式：

0 <= 標記 <= 位置 <= 限制 <= 容量
新創建的緩沖區總有一個 0 位置和一個未定義的標記。初始限制可以為 0，也可以為其他值，這取決於緩沖區類型及其構建方式。一般情況下，緩沖區的初始內容是未定義的。

******************************************************

clear() 使緩沖區為一系列新的通道讀取或相對放置 操作做好准備：它將限制設置為容量大小，將位置設置為 0。
通道讀取指從通道將數據讀入到buffer中，相對放置是從位置開始將數據插入到buffer中

flip() 使緩沖區為一系列新的通道寫入或相對獲取 操作做好准備：它將限制設置為當前位置，然後將位置設置為 0。
把限制設置為當前位置是為了保證數據的可靠性。讓從buffer寫入到通道的數據是buffer中確實是已經存在的數據。

rewind() 使緩沖區為重新讀取已包含的數據做好准備：它使限制保持不變，將位置設置為 0。
和clear()類似，只是不改動限制

這三個方法在源碼上就對緩沖區的數據不進行任何修改

⑨ Java多線程 Reactor模式和NIO

java nio從1.4版本就出現了，而且依它優異的性能贏得了廣大java開發愛好者的信賴。我很納悶，為啥我到現在才接觸，難道我不是愛好者，難道nio不優秀。經過長達半分鍾的思考，我意識到：時候未到。以前總是寫那些老掉牙的web程序，唉，好不容易翻身啦，現在心裡好受多了。因為真不想自己到了30歲，還在說，我會ssh，會ssi，精通javascript，精通資料庫，精通。。。人生苦短，要開拓點不是嗎？列為兄弟姐妹，沒看到外國的和尚已經開始鼓吹「雲里霧里」的？沒看到網路進入「框」啦，沒看到oracle的「格」啦。人家的經，隨他念，但是我們的確有好多路要走哦（牢騷怎麼這么多呀）。
現在終於到了我了解nio的時候了，突然發現有很多美妙程序的源碼，不得不爽一把（有邪念者，該打住啦，像我這樣）。
以下描述，為了說明問題，就提提歷史（類似的東西，網上一搜一大把，但是希望你能在這里止步，知道到底是怎麼回事。如果還是不清楚，咱就站內溝通！）。
在我（剛）看nio的這段時間里，主要接觸了幾個東西，就是關於server和client。java之前的io完全可以勝任，但是效率不高，為何效率不高呢？
===============history==start===============
//TODO:finish the old style of server and socket data transion.
ServerSocket socket = new ServerSocket(80);
while (true) {
final Socket connection = socket.accept();
handleRequest(connection);
}
===============history==end in the future================
在上面的代碼片段中，我們只能是一個request一個的進行處理。這使得所有的請求都阻塞了。如果我們再改變一下，將handleRequest方法封裝到線程中處理：
if(connection = null){
new Thread(new Runnable(){
public void run(){
handleRequest(connection);
}
public void handleRequest(Socket conn){
//do actions
}
}).start();
}
伺服器端的資源是有限的，我們這里僅僅是從線程角度來擴展，但是這種處理依然是阻塞的處理方式。首先，僅僅是建立連接（socket），就佔用了伺服器的線程資源。如果客戶端還沒有發出相應的數據請求，那麼伺服器就要一直等待他們的數據流過來，然後再進行讀取，如此往復。。。一直都blocking。伺服器處在一個高負荷狀態中。
NIO出來之後，進入改革開放時期，有了這么幾個角色，ServerSocketChannel,SelectionKey,Selector.
這幾個角色都是做什麼用的呢？需要了解一下reactor模式（反應堆模式）。
作為服務端，如果什麼操作都要依賴於客戶端，很多操作都阻塞，如上面的代碼片段所示