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模式（反应堆模式）。
作为服务端，如果什么操作都要依赖于客户端，很多操作都阻塞，如上面的代码片段所示