Flink是使用 JVM 的大数据开源计算框架，基于 JVM 的数据分析引擎都需要面对将大量数据存到内存中，这就不得不面对 JVM 存在的几个问题：

1. Java 对象存储密度低。一个只包含 boolean 属性的对象占用了16个字节内存: 对象头占了8个,boolean 属性占了1个,对齐填充占了7个。而实际上只需要一个bit就够了。

• Full GC 会极大地影响性能, 尤其是为了处理更大数据而开了很大内存空间的JVM来说, GC 会达到秒级甚至分钟级。
• OOM 问题影响稳定性。OutOfMemoryError是分布式计算框架经常会遇到的问题, 当JVM中所有对象大小超过分配给JVM的内存大小时, 就会发生OutOfMemoryError错误, 导致JVM崩溃, 分布式框架的健壮性和性能都会受到影响。

对于第一个问题，如果采用基类存储就可以解决。而第二个问题，可以考虑是使用直接内存和内存池来解决 Full GC 的问题。OOM 问题需要支持内存数据溢写到磁盘，即支持内存数据的序列化和反序列化。这里不使用 JDK 原始 buffer 的原因是 JDK Buffer只支持存储相同固定类型的实例数据，而实际上流式数据处理的总是一行数据，且数据要支持可扩展的类系统。

因此，Flink 选择了实现自己管理的内存单元和可扩展的类型系统，也就是接下来介绍的 Buffer框架(Memory Segment) 和对应的 TypeSerializer。

前面介绍过Java Buffer使用的内存分堆内内存(Heap)和堆外内存(No Heap)，本文将介绍DirectBuffer的实现原理，以DirectByteBuffer为例¹。

Java 传统 IO 是面向流的，流的处理是单向「只能从输入流中读取数据，或是向输出流中写入数据」且阻塞的。通常都是从输入流中边读取数据边处理数据，这样 IO 处理效率就会很低，基于上述原因，JDK1.4 引入了 NIO，而 NIO 是面向 Buffer 的，在处理 IO 操作的时候，会一次性将 Channel 中的数据读取到 Buffer 中然后在做后续处理，向 Channel 中写入数据也是一样，也是需要一个 Buffer 做中转，然后将 Buffer 中的数据批量写入 Channel 中。通过增加Buffer支持了数据的灵活处理。

除此之外，Nio Buffer 还提供了堆外的直接内存和内存映射相关的访问方式，来避免内存之间的来回拷贝，所以即使在传统 IO 中用到了 BufferedInputStream 也还是没办法和 Nio Buffer 相匹敌。本文将结合源码介绍 ByteBuffer^[本文JDK源码基于Java8]。