direct

Netty 高性能之ByteBuf Netty 高性能的原因除了前面提到的 NIO 的 Reactor 线程模型, 零拷贝也是其高性能的一个重要原因. 零拷贝 省去了数据从用户进程到内核的拷贝(jvm 堆内的数据 os 是不能直接使用的, 要让os可以使用的话, 需要将堆内的数据拷贝一份到堆外) CompositeByteBuf 复合多个 ByteBuf, netty使用的是逻辑上的关联, 对外提供访问的统一接口, 而不是重新申请内存再将数据写入新的 ByteBuf Netty 的 ByteBuf 类型 Pooled(池化)、Unpooled(非池化) Direct(直接缓冲区/堆外)、Heap(jvm堆内) unsafe(unsafe 调用的本地方法)、safe(一般也不会这么说, 这是相对于 unsafe, 指的jvm 堆内的操作) Netty 默认都会优先使用 unsafe 的实现, 池化/非池化(Pooled/Unpooled): Netty 先申请一块连续的空间作为 ByteBuf 池, 需要用到的时候直接去池里面取, 用完之后返还给 ByteBuf 池, 而不需要每次要用 ByteBuf 的时候都去申请. 堆外对象的创建比堆内的耗时. 总结: 池化的作用就是加快程序获取到操作的对象 堆外/堆内(direct/heap): 堆内指的在 JVM 中的数据,申请

JVM可以使用的内存分外2种： 堆内存和堆外内存 . 堆内存完全由JVM负责分配和释放，如果程序没有缺陷代码导致内存泄露，那么就不会遇到java.lang.OutOfMemoryError这个错误。 使用堆外内存，就是为了能直接分配和释放内存，提高效率。JDK5.0之后，代码中能直接操作本地内存的方式有2种：使用未公开的Unsafe和NIO包下ByteBuffer。 关于Unsafe对象的简介和获取方式,可以参考：http://blog.csdn.net/aitangyong/article/details/38276681 使用ByteBuffer分配本地内存则非常简单，直接ByteBuffer.allocateDirect(10 * 1024 * 1024)即可。 C语言的内存分配和释放函数malloc/free，必须要一一对应，否则就会出现内存泄露或者是野指针的非法访问。java中我们需要手动释放获取的堆外内存吗？ 我们一起来看看NIO中提供的ByteBuffer 我们将最大堆外内存设置成40M，运行这段代码会发现：程序可以一直运行下去，不会报OutOfMemoryError。如果使用了-verbose:gc -XX:+PrintGCDetails，会发现程序频繁的进行垃圾回收活动。那么 DirectByteBuffer究竟是如何释放堆外内存的？ 我们修改下JVM的启动参数

要在 AWS Direct Connect 位置使用 AWS Direct Connect，您的网络必须满足以下条件之一： 您的网络托管于现有的 AWS Direct Connect 节点。有关可用 AWS Direct Connect 位置的更多信息，请参阅 AWS Direct Connect 产品详细信息 。 您正与作为 AWS Partner Network (APN) 成员的 AWS Direct Connect 合作伙伴开展合作。有关信息，请参阅 支持 AWS Direct Connect 的 APN 合作伙伴 。 您正与独立的服务供应商合作连接到 AWS Direct Connect。 此外，您的网络必须符合以下条件： 您的网络必须使用具有适用于 1 GB 以太网的 1000BASE-LX (1310nm) 收发器或适用于 10 GB 以太网的 10GBASE-LR (1310nm) 收发器的 单模光纤 。 必须禁用端口的自动协商功能。必须手动配置端口速度和 全双工模式。 必须跨整个连接 (包括中间设备) 支持 802.1Q VLAN 封装。 您的设备必须支持边界网关协议 (BGP) 和 BGP MD5 认证。 (可选) 您可以在网络上配置双向转发检测 (BFD)。异步 BFD 对 AWS Direct Connect 虚拟接口自动启用

今天面试一个senior的老同事 聊的GC很细节 当聊到jvm优化时 老兄提到了 给jvm加参数取消 System.gc() 来避免gc的频繁调动 因为在netty中显式调用的地方所以有点疑惑 人走后特意查了下 soga Direct Memory满了之后，系统不会自动回收这段内存； 而是要等Tenured Generation满触发GC时，Direct Memory才会被跟着回收。 所以这一块很容易发生内存溢出. 为了防止这种事发生，你要么不把Heap设的过多，该Full GC的时候就Full GC; 要么在JVM参数里不禁止System.gc()，因为NIO的实现里会自己调用System.gc() 另附上 -XX:+DisableExplicitGC //禁用System.gc()调用 来源： oschina 链接： https://my.oschina.net/u/553214/blog/215528