bytebuffer

I'm working on something that uses ByteBuffers built from memory-mapped files (via FileChannel.map() ) as well as in-memory direct ByteBuffers. I am trying to understand the concurrency and memory model constraints. I have read all of the relevant Javadoc (and source) for things like FileChannel, ByteBuffer, MappedByteBuffer, etc. It seems clear that a particular ByteBuffer (and relevant subclasses) has a bunch of fields and the state is not protected from a memory model point of view. So, you must synchronize when modifying state of a particular ByteBuffer if that buffer is used across

I'm working on some SocketChannel -to- SocketChannel code which will do best with a direct byte buffer--long lived and large (tens to hundreds of megabytes per connection.) While hashing out the exact loop structure with FileChannel s, I ran some micro-benchmarks on ByteBuffer.allocate() vs. ByteBuffer.allocateDirect() performance. There was a surprise in the results that I can't really explain. In the below graph, there is a very pronounced cliff at the 256KB and 512KB for the ByteBuffer.allocate() transfer implementation--the performance drops by ~50%! There also seem sto be a smaller

What options do I have to make a ByteBuffer thread safe? It is known that it is not thread safe as it safes position, limit and some(/all?) methods depend on this internal state. For my purposes it will be sufficient if multiple read-threads are safe, but for other future visitors I would like to know what technics/tricks/traps I need to know to make it completely thread safe. What I have in mind: Synchronizing or using ReadWrite locks for all methods. Probably the slowest approach (?) Subclassing ByteBuffer and avoid persisting thread-bound state like position etc. And throwing exceptions

ByteBuffer类是在Java NIO中常常使用的一个缓冲区类，使用它可以进行高效的IO操作，但是，如果对常用方法的理解有错误，那么就会出现意想不到的bug。 ByteBuffer类的常用方法 先来看看一个基本的程序 public void test() throws IOException { ByteBuffer buff = ByteBuffer.allocate(128); FileChannel fin = null; FileChannel fout = null; try { fin = new FileInputStream("filein").getChannel(); fout = new FileOutputStream("fileout").getChannel(); while(fin.read(buff) != -1) { buff.flip(); fout.write(buff); buff.clear(); } } catch (FileNotFoundException e) { } finally { try { if(fin != null) { fin.close(); } if(fout != null) { fout.close(); } } catch(IOException e) { throw e; } } } 　　

参考： http://ifeve.com/selectors/ 参考： https://www.ibm.com/developerworks/cn/education/java/j-nio/j-nio.html netty的NioEventLoop类的实现也是类似 这些都是在实践中踩过雷的，今天某应用再次踩雷，把遇到的几个雷都收集一下，给后来者参考。 1.即使是accept事件，没有真正的read和write,Channel也要关闭，否则unix domain socket会被泄漏（WINDOWS更可怕），因为NIO的每个 Channel上都有两个FD用来监听事件（接收和发送走不同的FD）。 2.cancel事件导致CPU占用100%， http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6403933 其原因就是调用key.cancel()时底层在下一次seelect前并没有真正的取消。导致等待select事件返回却又没有返回我们注册的key.这个事件不断地 循环触发，CPU一直处理返回 key为0的select()调用。解决方法有两种，一是在key.cancel()后立即selectNow();但是如果是多线程并发操作，有 可能这两行语句中间线程被切换，使得key.cancel()后没有立即执行 selectNow()

缓冲区(Buffer)就是在内存中预留指定大小的存储空间用来对输入/输出(I/O)的数据作临时存储，这部分预留的内存空间就叫做缓冲区： 使用缓冲区有这么两个好处： 1、减少实际的物理读写次数 2、缓冲区在创建时就被分配内存，这块内存区域一直被重用，可以减少动态分配和回收内存的次数 举个简单的例子，比如A地有1w块砖要搬到B地 由于没有工具（缓冲区），我们一次只能搬一本，那么就要搬1w次（实际读写次数） 如果A，B两地距离很远的话（IO性能消耗），那么性能消耗将会很大 但是要是此时我们有辆大卡车（缓冲区），一次可运5000本，那么2次就够了 相比之前，性能肯定是大大提高了。 而且一般在实际过程中，我们一般是先将文件读入内存，再从内存写出到别的地方 这样在输入输出过程中我们都可以用缓存来提升IO性能。 所以，buffer在IO中很重要。在旧I/O类库中（相对java.nio包）中的BufferedInputStream、BufferedOutputStream、BufferedReader和BufferedWriter在其实现中都运用了缓冲区。java.nio包公开了Buffer API，使得Java程序可以直接控制和运用缓冲区。 在Java NIO中，缓冲区的作用也是用来临时存储数据，可以理解为是I/O操作中数据的中转站。缓冲区直接为通道(Channel)服务

一：NIO与IO的区别 　　1.NIO面对的是缓冲区，IO面对的是流 　　2.NIO是非阻塞的，IO是阻塞的 　　3.NIO中引入了选择器 二：既然NIO面对的是缓冲区，那就先来了解缓冲区 　　1.NIO中Buffer负责存储，Buffer底层采用的是数组，可以存储不同数据类型，提供了相应的缓冲区（ByteBuffer,IntBuffer......），对于缓冲区的管理一致，通过allocate获取缓冲区 　　2.缓冲区存取数据的2个方法,put()存入,get()取出 　　3.缓冲区的4个核心属性 　　　　a.capacity:容量,最大存储数据的容量,一旦声明不能改变 　　　　b.limit:界限，表示缓冲区中可以操作数据的大小,(limit后面的数据不能进行读写) 　　　　c.limit:界限，表示缓冲区中可以操作数据的大小,(limit后面的数据不能进行读写) 　　　　d.position:位置，（表示缓冲区中正在操作数据的位置） 　　　　 e: 规则：position<=limit<=capacity @Test public void test1(){ String str="abcde"; //1.分配指定大小的缓冲区 ByteBuffer buf = ByteBuffer.allocate(1024); System.out.println("allocatt...

I have a memory leak that I have isolated to incorrectly disposed direct byte buffers. ByteBuffer buff = ByteBuffer.allocateDirect(7777777); The GC collects the objects that harbor these buffers but does not dispose of the buffer itself. If I instantiate enough of the transient objects containing buffers, I get this encouraging message: java.lang.OutOfMemoryError: Direct buffer memory I have been searching up this problem and apparently buff.clear(); and System.gc(); do not work. I suspect that somewhere your application has a reference to the ByteBuffer instance(s) and that is preventing it

Java equivalents of malloc() , new , free() and delete (ctd) Continued from our introduction to memory management operators in C/C++ and Java. A Java equivalent of the malloc() function...? If you've read the previous page on memory management and new in Java, you may be wondering why the current section on malloc() even exists. We've just stated that in Java, all memory has to be accessed via well-defined objects. In C/C++, on the other hand, malloc() gives us a pointer to an arbitrary block of memory . And in Java, there's no such thing, right? Well, strictly speaking this is true: there isn