首先要分析一下，Channe!InboundHandler是否是线程安全的？
初步的判断，每个线程都会有一个独立的Channe!InboundHandler实例化对象。所以如果没有static的类变量，那么就是线程安全的。
Bytebuf提供接口方法要比ByteBuffer简洁并强大。这篇在ByteBuf基础上学习下主要的ByteBuf，包括：poolHeapByteBuff、pooledDirectByteBuf、UpooledHeapByteBuf、UnpooledDirectByteBuf。
Bytebuf分类分为2个维度，
第一个维度是堆非堆维度
堆缓冲区(HeapByte)
是将数据存储在JVM堆空间中，特点是在内存的分配和回收速度快，可以被JVM自动回收，缺点是如果进行socket的I/O读写，需要额外一次内存复制，将堆内存对应的缓冲区复制到内核Channel中，性能会有一定程度下降。
直接内存(DirectByte)
非堆内存，在堆外进行内存分配，相比于堆内存，分配和回收速度会慢一些，但将它写入或从socket channel中读取时，由于少一次内存复制，速度比堆内存快。通常在I/OI/O通信线程的读写缓冲区使用DirectByteBuf，后端业务消息的编解码模块使用HeapByteBuf，可以达到很好的性能效果。直接内存，需要程序员进行回收。JVM无法进行回收。
第二个维度：内存回收角度
从内存回收角度看，ByteBuf分为两类：基于pooled的和普通的ByteBuf。两者的区别是基于pooled的ByteBuf可以重复利用，自己维护一个内存池，可以循环利用创建的ByteBuf，提升内存使用效率，降低由于高负载导致的频繁GC。
所以，2×2=4,就出现4个类别
UnpooledHeapByteBuf：
UnpooledHeapByteBuf：最基于堆内存进行内存分配的字节缓冲区，它没有基于对象地技术实现，这就意味着每次IO的读写，都会创建一个新的UnpooledHeapByteBuf：频繁的进行大块内存的分配和回收对性能会造成一定影响，但是相比于堆外内存的申请和释放， 它的成本还是低一些.也不容易出现问题，因此在满足性能的情况下推荐UnpooledHeapByteBuf.
Server端采用的是bind
client端采用是Connect．在Connect端也可以连接多个，在书中，有个例子关于泄漏，在Upgrade上的第２章上有
在第四章的例子上，我认为也不一定需要采用Promise来接受数据，直接放入到ｈａｎｄｌｅ中应该是可以的．
Client端写程序，那么在ａｃｔｉｖｅ中，执行用户线程，然后再写．不会进入
QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
---------------------
作者：qq_18535263
来源：CSDN
原文：https://blog.csdn.net/qq_18535263/article/details/79373878
版权声明：本文为博主原创文章，转载请附上博文链接！
问题
public static void schedule() {
ScheduledExecutorService executor =
Executors.newScheduledThreadPool(10);
ScheduledFuture future = executor.schedule(
new Runnable() {
@Override
public void run() {
System.out.println("Now it is 60 seconds later");
}
}, 60, TimeUnit.SECONDS);
//...
executor.shutdown();
}
这一段代码执行后，是一个线程池中每个都执行吗？
从线程池中，选择一个线程来执行的方法？在一个线程中，有无任务的队列？
现在执行之后，为什么要手动的shutdown()？不能自动的回收吗？
ThreadPoolExecutor类可设置的参数主要有：
corePoolSize
在创建了线程池后，默认情况下，线程池中并没有任何线程，而是等待有任务到来才创建线程去执行任务
请求ByteBuf 被Netty 框架申请后竟然没有被释放，（从堆内存转到直接内存中）
策略1：业务ChanneInboundHandler 继承自SimpleChanneInboundHandler
策略2：直接调用ctx.fireChannelRead(msg)，由最后的tail来释放。如果不调用这个，那么到这个handle，直接就结束了（？）
发送的消息
被Netty的框架自动进行释放
客户端的channelActive，什么时候执行？
ByteBuf respMsg = allocat。r . heapBuffer(b。dy . length);
respMsg.writeBytes(body) ；／／作为示例，简化处理，将请求返回
ctx.writeAndFlush(respMsg);
writeBytes主要是干什么？
4.1.X的版本调整
channelRead0:继承了SimpleChannelInboundHandler,它应该是多一个释放了消息的资源，
channelRead:继承了ChannelInboundHandlerAdapter
