bytebuffer

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 现象： 先连续发几十个很小很小的包(<10 byte) 再突然发一个大小64byte的包 这时你会发现mina就会出现以下错误 java.nio.BufferUnderflowException at java.nio.HeapByteBuffer.get(Unknown Source) at org.apache.mina.core.buffer.AbstractIoBuffer.get(AbstractIoBuffer.java:419) at org.apache.mina.core.buffer.AbstractIoBuffer.get(AbstractIoBuffer.java:827) at com.labox.common.net.ProtocolHandler.messageReceived(ProtocolHandler.java:81) at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:752) at org.apache.mina.core.filterchain.DefaultIoFilterChain

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 最近在做通信和传输的项目，大量的使用 NIO 和 Mina ，虽然之前一直对这部分比较关注，但是还没有好好的总结一下这方面的内容。今天想写点儿 NIO 里最基本的一个类 ByteBuffer 。至于 Mina 中的 IoBuffer ，我们可以先看 Mina API 中的描述： A byte buffer used by MINA applications. This is a replacement for ByteBuffer. Please refer to ByteBuffer documentation for preliminary usage 。 当然，接下去也有写到： MINA does not use NIO ByteBuffer directly for two reasons ，至于这 Two Reasons ，我们将在后面的比较中展开。 ByteBuffer 继承了 Buffer ，对 Buffer 的理解可以说是 NIO 的入门。在 Buffer 中有 4 个重要的 Attributes ： Capacity: the capacity is set when the buffer is created and can never be changed 。 Limit: the

前言 最近工作比较忙，在工作项目中，看了很多人都自己实现了一套数据任务处理机制，个人感觉有点乱，且也方便他人的后续维护，所以想到了一种数据处理模式，即生产者、缓冲队列、消费者的模式来统一大家的实现逻辑。 下面时是对Disruptor基本使用的演示。使用中需要引入依赖 <dependency> <groupId>com.lmax</groupId> <artifactId>disruptor</artifactId> <version>3.4.2</version> </dependency> 名称解释 Ring Buffer 环境的缓存区,3.0版本以前被认为是Disruptor的主要成员。3.0版本以后，环形缓冲区只负责通过Disruptor的事件方式来对数据进行存储和更新。在一些高级的应用场景中，Ring Buffer可以由用户的自定义实现完全替代。 Sequence Disruptor使用Sequence作为一种方法来确定特定组件的位置。每个使用者（EventProcessor）与Disruptor本身一样维护一个序列。大多数并发代码依赖于这些序列值的移动，因此序列支持AtomicLong的许多当前特性。事实上，两者之间唯一真正的区别是序列包含额外的功能，以防止序列和其他值之间的错误共享。 Sequencer Sequencer是真正的核心，该接口的两个实现（单生产者，

前言 最近工作比较忙，在工作项目中，看了很多人都自己实现了一套数据任务处理机制，个人感觉有点乱，且也方便他人的后续维护，所以想到了一种数据处理模式，即生产者、缓冲队列、消费者的模式来统一大家的实现逻辑。 下面时是对Disruptor基本使用的演示。使用中需要引入依赖 <dependency> <groupId>com.lmax</groupId> <artifactId>disruptor</artifactId> <version>3.4.2</version> </dependency> 名称解释 Ring Buffer 环境的缓存区,3.0版本以前被认为是Disruptor的主要成员。3.0版本以后，环形缓冲区只负责通过Disruptor的事件方式来对数据进行存储和更新。在一些高级的应用场景中，Ring Buffer可以由用户的自定义实现完全替代。 Sequence Disruptor使用Sequence作为一种方法来确定特定组件的位置。每个使用者（EventProcessor）与Disruptor本身一样维护一个序列。大多数并发代码依赖于这些序列值的移动，因此序列支持AtomicLong的许多当前特性。事实上，两者之间唯一真正的区别是序列包含额外的功能，以防止序列和其他值之间的错误共享。 Sequencer Sequencer是真正的核心，该接口的两个实现（单生产者，

Java NIO原生支持scatter和gather。Scatter/Gather是从channel中读取或者是向channel中写入时的概念。 一个scatter类型的reading操作，就是一次读操作中会读取多个buffer。 一个gather类型的writing操作，就是一次向channel中写入多个buffer。 在需要分别处理传输数据的各个部分的情况下，Scatter/Gather非常有用。例如，一个消息包含一个header和一个body，你可能需要把header和body分成两个buffer来处理。这样可能会使工作更加容易。 Scattering Reads ByteBuffer header = ByteBuffer.allocate(128); ByteBuffer body = ByteBuffer.allocate(1024); ByteBuffer[] bufferArray = { header, body }; channel.read(bufferArray); 注意，buffer加入数组的顺序就是传递给channel的处理顺序。一旦buffer读满了，channel就会移动到下一个buffer。 事实上scattering的读操作，直到一个buffer满了才会移动到下一个buffer的特性，导致它不适合动态大小的buffer。换言之

从实践角度重新理解BIO和NIO https://mp.weixin.qq.com/s/rsvAmmoJiseEmjChI95m6Q 1 bio的2次阻塞与缺陷 服务器端在启动后，首先需要等待客户端的连接请求（第一次阻塞），如果没有客户端连接，服务端将一直阻塞等待，然后当客户端连接后，服务器会等待客户端发送数据（第二次阻塞），如果客户端没有发送数据，那么服务端将会一直阻塞等待客户端发送数据。 BIO会产生两次阻塞，第一次在等待连接时阻塞，第二次在等待数据时阻塞。 当我们的服务器接收到一个连接后，并且没有接收到客户端发送的数据时，是会阻塞在read()方法中的，那么此时如果再来一个客户端的请求，服务端是无法进行响应的。在不考虑多线程的情况下，BIO是无法处理多个客户端请求的。 2 多线程的bio 我们只需要在每一个连接请求到来时，创建一个线程去执行这个连接请求，就可以在BIO中处理多个客户端请求了，这也就是为什么BIO的其中一条概念是服务器实现模式为一个连接一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理。 while (true) { System.out.println(); System.out.println("服务器正在等待连接..."); Socket socket = serverSocket.accept(); 【重点阻塞】 new Thread