bytebuffer

一，简介Buffer是java nio使用的缓冲区，所有的数据都是通过缓冲区处理的，在读取数据时，他是直接读到缓冲区中的，在写数据时，写入缓冲区，任何时候使用nio的数据，都是通过缓冲区进行操作的 缓冲区实质上是一个数组。通常它是一个字节数组(ByteBuffer),也可以使用其他种类的数组。但是一个缓冲区不仅仅是一个数组，缓冲区提供了对数据的结构化访问以及维护读写位置(limit) 等信息。 最常用的缓冲区是ByteBuffer，一个ByteBuffer提供了一组功能用于操作byte数组。 除了ByteBuffer,还有其他的一些缓冲区，事实上，每一种Java基本类型(除了Boolean 类型)都对应有一种缓冲区，具体如下。 ByteBuffer:字节缓冲区 CharBuffer:字符缓冲区 ShortBuffer:短整型缓冲区 IntBuffer:整形缓冲区 LongBuffer:长整形缓冲区 FloatBuffer:浮点型缓冲区 DoubleBuffer:双精度浮点型缓冲区 二，类主要成员变量 　　mark：此字段可备份读写地址 　　position：当前buffer读写的位置 　　limit：写模式-->当前最大可写长度，读模式-->当前最大可读长度 　　capacity：buffer当前容量 　　address：buffer在内存中的地址 来源：博客园 作者： dybe

进程执行I/O操作，归结起来就是向操作系统发出请求，它要么把缓存区例的数据排干（写），要么用数据把数据区填满（读）。进程使用这一机制处理所有数据进出操作。 进程使用read()系统调用，要求其缓存区被填满。内核随即向磁盘控制器发出命令，要求其从磁盘读取数据。通过DMA技术直接将磁盘中的数据写入内核内存缓存区，一旦磁盘控制器把缓存区填满，内存立即把数据从内核空间的里你是缓冲区拷贝到进程执行read()调用时指定的缓冲区。 根据发散/汇聚的概念，进程只需要一个系统调用，就能把一连串的缓冲区地址传递给操作系统。然后，内核就能顺序填充或排干多个缓冲区，读的时候将数据发散到多个用户空间缓冲区，写的时候再从多个缓冲区把数据汇聚起来。 前面提到设备控制器不能使用DMA直接存储到用户空间，需要从内核空间拷贝到用户空间。但在使用内存多重映射技术可以避免这种拷贝。 现代操作系统都使用虚拟内存，它有极大优点： 多个虚拟地址可以映射到同一个物理地址。 虚拟内存空间可能大于实际可用的硬件内存。 借助虚拟内存的特点，将内核空间中的缓冲区的虚拟地址和用户空间的缓冲区虚拟地址映射到一个物理地址（即内存多重映射技术）。 但这也是有前提的，内核与用户缓冲区必须使用相同的页对齐，缓冲区的大小还必须是磁盘控制块大小的倍数。 确定请求的数据分布在文件系统的哪些页，这些页不一定都是连续的 在内核空间种分配足够的页

试图按照http://dblab.xmu.edu.cn/blog/971-2/里面的教程编译Scala代码时，出现报错： hadoop@ubun:/usr/local/spark/code/wjw/wordcount$ scala test.scala error: Compile server encountered fatal condition: java.nio.ByteBuffer.clear ( ) Ljava/nio/ByteBuffer ; java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear ( ) Ljava/nio/ByteBuffer ; Scala版本是, 2.11.12 进入Scala看一下， java是8，scala官网显示2.11.12应该使用java9或者10,那就修改环境变量。 打开 ~/.bashrc 修改一下java的环境变量，改为 JAVA_PATH = /usr/lib/jvm/java-11-openjdk-amd64 记得“source ~/.bashrc”否则不会生效，再打开Scala看看 已经变成java10了 再运行一下 hadoop@ubun:/usr/local/spark/code/wjw/wordcount$ scala test.scala 报错 error:

概述 nio是另一种处理io的方式 非阻塞io,基于缓冲区进行操作,一个线程可处理多个io请求 入门参考: http://www.iteye.com/magazines/132-Java-NIO http://www.ibm.com/developerworks/cn/education/java/j-nio/j-nio.html 和io进对比 区别 面向流和面向缓冲区 io是面向流的 nio面向缓冲区 阻塞与非阻塞 io是阻塞的 nio是非阻塞的(read方法立即返回) 线程利用 io是一个线程管理一个io请求 nio是一个线程可以管理多个io请求(通过selectors监听并选择准备就绪的通道) 通道和缓冲区(Channel和Buffer) 概述 NIO是基于通道(Channel)和缓冲区(Buffer)进行操作的 数据总是从通道读取到缓冲区中,或者从缓冲区写入到通道中 通道 通道就像io中的流一样,可以从流对象获得 区别在于通道是双向的,流只能在一个方向上移动(一个输入流,一个输出流),但一个通道可同时应用于读写请求 缓冲区 本质上是一个数组,是内存中的一小块区域,通常是一个字节数组 读取数据时,数据先读到缓冲区中,再读到通道中 写入数据时,数据先写到缓冲区中,再写到通道中 常用通道 FileChannel 文件通道 DatagramChannel UDP通道

目录： Java NIO 学习笔记（一）----概述，Channel/Buffer Java NIO 学习笔记（二）----聚集和分散，通道到通道 Java NIO 学习笔记（三）----Selector Java NIO 学习笔记（四）----文件通道和网络通道 Java NIO 学习笔记（五）----路径、文件和管道 Path/Files/Pipe Java NIO 学习笔记（六）----异步文件通道 AsynchronousFileChannel Java NIO 学习笔记（七）----NIO/IO 的对比和总结 学完 NIO 和 IO 后，有一个问题：什么时候应该使用 IO，什么时候应该使用 NIO ?本文将尝试阐明 NIO 和 IO 之间的差异，并提供它们的用例，以及它们对程序代码的设计影响。 NIO 和 IO 之间的主要区别 IO NIO 以 Stream 为导向 以 Buffer 为导向 阻塞 IO 非阻塞 IO 选择器 以 Stream 为导向 vs 以 Buffer 为导向 NIO 和 IO 之间的第一个重要区别是 IO 是面向流的，其中 NIO 是面向缓冲区的。 那么，这意味着什么？ 面向流的 IO 意味着可以从流中一次读取一个或多个字节，可以按我们的意愿使用读取的字节。 它们不会缓存在任何地方，此外，无法在流中的将数据前后移动。 如果需要将读取的数据前后移动

java.nio.charset包中提供了Charset类，它继承了Comparable接口；还有CharsetDecoder、CharsetEncoder编码和解码的类，它们都是继承Object类。 Java中的字符使用Unicode编码，每个字符占用两个字节，16个二进制位，向ByteBuffer中存放数据的时候需要考虑字符的编码，从中读取的时候也需要考虑字符的编码方式，也就是编码和解码。 1.获取字符集有如下两种方式 //返回指定的字符集CharSet Charset charset = Charset.forName("utf8"); //返回虚拟机默认的字符集CharSet Charset charset = Charset.defaultCharset(); 2.接下来我们使用字符集CharSet创建一个编码器和一个解码器 //编码器 CharsetEncoder encoder = charset.newEncoder(); //解码器 CharsetDecoder decoder = charset.newDecoder(); 3.使用编码器和解码器解析数据 //编码，传入CharBuffer ByteBuffer bytebuffer = encoder.encode(in); //解码，传入ByteBuffer CharBuffer charbuffer =

While processing multiple gigabyte files I noticed something odd: it seems that reading from a file using a filechannel into a re-used ByteBuffer object allocated with allocateDirect is much slower than reading from a MappedByteBuffer, in fact it is even slower than reading into byte-arrays using regular read calls! I was expecting it to be (almost) as fast as reading from mappedbytebuffers as my ByteBuffer is allocated with allocateDirect, hence the read should end-up directly in my bytebuffer without any intermediate copies. My question now is: what is it that I'm doing wrong? Or is

Has anyone has ever seen an implementation of java.nio.ByteBuffer that will grow dynamically if a putX() call overruns the capacity? The reason I want to do it this way is twofold: I don't know how much space I need ahead of time. I'd rather not do a new ByteBuffer.allocate() then a bulk put() every time I run out of space. In order for asynchronous I/O to work, you must have continuous memory. In C you can attempt to re-alloc an array, but in Java you must allocate new memory. You could write to a ByteArrayOutputStream , and then convert it to a ByteBuffer at the time you are ready to send it

主要阐述点： 1、同步/异步 or 阻塞/非阻塞 2、网络模型演进 3、代码示例 一、同步/异步 or 阻塞/非阻塞 同步/异步：核心点在于是否等待结果返回。同步即调用者必须等到结果才返回，而异步则可立即返回无需等待结果，通过后期异步回调、状态检查等方式得到结果。 阻塞/非阻塞：核心点在于执行线程是否会阻塞。阻塞，例如在读操作中如果内核数据未准备好则会当阻塞读线程；而非阻塞，在内核数据未准备好前读线程无需等待，可以忙里偷闲干别的事情， 但是需要定期检查。 二、网络模型演进 1、原始版BIO： 单线程监听链接，每次只处理一个链接请求且读写阻塞。缺点：每次只能处理一个请求，读写阻塞。 2、线程版BIO： 单线程监听链接，可同时处理多个请求，每次分配一个线程处理一个链接请求，线程之间读写非阻塞。缺点：线程可能开设过多导致机器瓶颈，线程过多导致cpu上下文切换消耗大， 线程销毁浪费资源，单线程内部读写依然阻塞。 3、线程池版BIO： 单线程监听链接，可同时处理多个请求，每次将链接请求加入线程池工作队列，减少【线程版BIO】线程创建过多问题，线程之间读写非阻塞。缺点：存在客户链接数量限制， 单线程内部读写依然阻塞。 4、JDK4版本NIO：单线程监听链接，可同时处理多个请求，基于事件驱动形式。Selector封装操作系统调用(如linux epoll)，每个客户端链接用通道Channel表示