前端电商网站登录界面怎么做wordpress云盘视频播放器
Netty Home
Netty GitHub
Netty简介
Netty是由JBOSS提供的一个java开源框架，现为 Github上的独立项目。Netty提供异步的、事件驱动的网络应用程序框架和工具，用以快速开发高性能、高可靠性的网络服务器和客户端程序。
也就是说，Netty 是一个基于NIO的客户、服务器端的编程框架，使用Netty 可以确保你快速和简单的开发出一个网络应用，例如实现了某种协议的客户、服务端应用。Netty相当于简化和流线化了网络应用的编程开发过程，例如：基于TCP和UDP的socket服务开发。
“快速”和“简单”并不用产生维护性或性能上的问题。Netty 是一个吸收了多种协议（包括FTP、SMTP、HTTP等各种二进制文本协议）的实现经验，并经过相当精心设计的项目。最终，Netty 成功的找到了一种方式，在保证易于开发的同时还保证了其应用的性能，稳定性和伸缩性。
本质
网络应用程序框架
实现
异步、事件驱动
特性
高性能、可维护、快速开发
用途
开发服务器和客户端
优势
- 支持常用的应用层协议
- 解决传输中粘包、半包问题
- 支持流量整性
- 完善的断连、Idle 等异常处理等
三种 I/O 模式
- 阻塞与非阻塞
阻塞：没有数据传过来时，读会阻塞直到有数据；缓冲区满时，写操作也会阻塞。非阻塞遇到这种情况，会直接返回。连接数高的情况下，阻塞 -> 耗资源、效率低。 - 异步与同步
数据就绪后自己去读就是同步，数据就绪直接读好再回调给程序是异步。
对于 Nio 与 Bio 来说，特定场景下如连接数少，并发度低，BIO 性能不输 NIO。
通用的 NIO 实现（Common）在 Linux 下也是使用 epoll，Netty 重新单独实现，暴露了更多的可控参数，例如：JDK 的 NIO 默认实现是水平触发，Netty 是边缘触发（默认）和水平触发可切换；Netty 实现的垃圾回收更少、性能更好；
对于 ServerSocketChannel：工厂模式 + 泛型 + 反射实现
三种 Reactor
Reactor 及三种版本
Reactor 是一种开发模式，模式的核心流程：
注册感兴趣的事件 -> 扫描是否有感兴趣的事件发生 -> 事件发生后做出相应的处理。
Thread-Per-Connection 模式
Reactor 模式 V1：单线程
Reactor 模式 V2：多线程
Reactor 模式 V3：主从多线程
在 Netty 中使用 Reactor 模式
TCP 粘包/半包
什么是粘包和半包
- 粘包的主要原因：
发送方每次写入数据 < 套接字缓冲区大小
接收方读取套接字缓冲区数据不够及时 - 半包的主要原因：
发送方写入数据 > 套接字缓冲区大小
发送的数据大于协议的 MTU（Maximum Transmission Unit，最大传输单元），必须拆包 - 根本原因
TCP 是流式协议，消息无边界
说明：UDP 像邮寄的包裹，虽然一次运输多个，但每个包裹都有“界限”，一个一个签收，
所以无粘包、半包问题
解决粘包和半包问题的几种常用方法
Netty 对三种常用封帧方式的支持
常用的“二次”编解码方式
假设我们把解决半包粘包问题的常用三种解码器叫一次解码器，那么我们在项目中，除了可选的的压缩解压缩之外，还需要一层解码，因为一次解码的结果是字节，需要和项目中所使用的对象做转化，方便使用，这层解码器可以称为“二次解码器”，相应的，对应的编码器是为了将 Java 对象转化成字节流方便存储或传输。
- 一次解码器：ByteToMessageDecoder
io.netty.buffer.ByteBuf （原始数据流）-> io.netty.buffer.ByteBuf （用户数据） - 二次解码器：MessageToMessageDecoder
io.netty.buffer.ByteBuf （用户数据）-> Java Object
常用的“二次”编解码方式
• Java 序列化
• Marshaling
• XML
• JSON
• MessagePack
• Protobuf
• 其他
ch.pipeline().addLast(new ProtobufVarint32FrameDecoder());
ch.pipeline().addLast(new ProtobufDecoder(PersonOuterClass.Person.getDefaultInstance()));
ch.pipeline().addLast(new ProtobufVarint32LengthFieldPrepender());
ch.pipeline().addLast(new ProtobufEncoder());
keepalive 与 Idle 监测
keepalive
需要 keepalive 的场景包含三点，对端异常“崩溃”、对端在，但是处理不过来、对端在，但是不可达。
不做 keepalive 的后果，连接已坏，但是还浪费资源维持，下次直接用会直接报错。
TCP keepalive 核心参数：
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
当启用（默认关闭）keepalive 时，TCP 在连接没有数据通过的7200秒后发送 keepalive 消息，当探测没有确认时，按75秒的重试频率重发，一直发 9 个探测包都没有确认，就认定连接失效。
所以总耗时一般为：2 小时 11 分钟 (7200 秒 + 75 秒* 9 次)
应用层 keepalive
- 协议分层，各层关注点不同
传输层关注是否“通”，应用层关注是否可服务？ 服务器连接在，但是不定可以服务（例如服务不过来等） - TCP 层的 keepalive 默认关闭，且经过路由等中转设备 keepalive 包可能会被丢弃
- TCP 层的 keepalive 时间太长
默认 > 2 小时，虽然可改，但属于系统参数，改动影响所有应用
HTTP 属于应用层协议，但是常常听到名词“ HTTP Keep-Alive ”指的是对长连接和短连接的选择
Connection : Keep-Alive 长连接（HTTP/1.1 默认长连接，不需要带这个 header）
Connection : Close 短连接
Idle 监测
Idle 监测，只是负责诊断，诊断后，做出不同的行为，决定 Idle 监测的最终用途：
• 发送 keepalive :一般用来配合 keepalive ，减少 keepalive 消息。
Keepalive 设计演进：V1 定时 keepalive 消息 -> V2 空闲监测 + 判定为 Idle 时才发keepalive。
• V1：keepalive 消息与服务器正常消息交换完全不关联，定时就发送；
• V2：有其他数据传输的时候，不发送 keepalive ，无数据传输超过一定时间，判定为 Idle，再发 keepalive 。
直接关闭连接：
• 快速释放损坏的、恶意的、很久不用的连接，让系统时刻保持最好的状态。
• 简单粗暴，客户端可能需要重连。
实际应用中：结合起来使用。按需 keepalive ，保证不会空闲，如果空闲，关闭连接。
在Netty 中开启 TCP keepalive 和 Idle 检测
开启keepalive
Server 端开启 TCP keepalive
bootstrap.childOption(ChannelOption.SO_KEEPALIVE,true)
bootstrap.childOption(NioChannelOption.of(StandardSocketOptions.SO_KEEPALIVE), true)
提示：.option(ChannelOption.SO_KEEPALIVE,true) 存在但是无效
开启不同的 Idle Check
ch.pipeline().addLast(“idleCheckHandler", new IdleStateHandler(0, 20, 0, TimeUnit.SECONDS));
“锁”事
锁的对象和范围 -> 减少粒度
Synchronized method -> Synchronized block
锁的对象本身大小 -> 减少空间占用
AtomicLong -> Volatile long + AtomicLongFieldUpdater
锁的速度 -> 提高速度
高并发时：java.util.concurrent.atomic.AtomicLong -> java.util.concurrent.atomic.LongAdder
不同场景选择不同的并发类 -> 因需而变
Object.wait/notify -> CountDownLatch
衡量好锁的价值 -> 能不用则不用
对竞争的态度：乐观锁（java.util.concurrent 包中的原子类）与悲观锁（Synchronized)
等待锁的人是否公平而言：公平锁 new ReentrantLock (true)与非公平锁 new ReentrantLock ()
是否可以共享：共享锁与独享锁：ReadWriteLock ，其读锁是共享锁，其写锁是独享锁
内存使用
减少对像本身大小
用基本类型就不要用包装类
应该定义成类变量的不要定义为实例变量
对分配内存进行预估
对于已经可以预知固定 size 的 HashMap避免扩容
根据接受到的数据动态调整（guess）下个要分配的 Buffer 的大小
Zero-Copy
使用逻辑组合，代替实际复制
使用包装，代替实际复制
调用 JDK 的 Zero-Copy 接口
堆外内存
内存池
轻量级对象池实现 io.netty.util.Recycler