加了@Sharable却报“not a @Sharable handler”异常，是因为将未标注@Sharable的Handler实例重复添加到多个ChannelPipeline中，Netty在addLast()时校验失败。
为什么加了@Sharable却报“not a @Sharable handler”异常
这不是注解没生效，而是你**把同一个Handler实例重复添加到了多个ChannelPipeline里，但没加@Sharable**——Netty在addLast()时会做运行时校验，一旦发现非@Sharable的Handler被复用，立刻抛ChannelPipelineException: xxxHandler is not a @Sharable handler, so can't be added or removed multiple times.
- 典型场景：你在
ServerBootstrap.childHandler()里传了一个全局静态变量或Spring Bean（比如new EchoServerHandler()只创建一次），但Handler类上没加@Sharable - 反例写法：
public class EchoServerHandler extends ChannelInboundHandlerAdapter { ... } // 没注解<br>private static final EchoServerHandler SHARED = new EchoServerHandler();<br>// 然后在childHandler里用ch.pipeline().addLast(SHARED); → 必炸 - 关键点：校验发生在
addLast()调用时，不是类加载时；即使Handler本身线程安全，缺注解照样拒绝复用
@Sharable能随便加吗\_无状态是硬门槛
不能。加了@Sharable等于向Netty和所有协作者声明：“我这个Handler绝对没可变成员变量，跨线程读写也绝对安全”。一旦违反，轻则数据错乱，重则JVM崩溃。
- 常见踩坑：继承
ByteToMessageDecoder或ReplayingDecoder的子类——它们内部有cumulation、checkpoint等状态字段，天生不满足无状态，加@Sharable会在初始化时直接抛IllegalStateException: ChannelHandler XXX is not allowed to be shared - 安全做法：只对纯函数式Handler用
@Sharable，例如日志打印、心跳响应、协议头校验等不保存上下文的逻辑 - 验证方法：检查类里有没有非
final、非static、非线程局部（ThreadLocal）的字段；如果有，要么删掉，要么别共享
不加@Sharable就一定不能复用吗\_两种复用路径完全不同
不是不能复用，而是Netty强制你分清“复用意图”：一种是**开发者主动共享单例**（必须加@Sharable），另一种是**框架自动复用无状态实例**（如LoggingHandler这种官方提供的，自带注解）。
- 如果你写
pipeline().addLast(new MyHandler())——每次连接都new一个，加不加@Sharable都没意义，Netty根本不校验 - 但如果你写
private static final MyHandler INSTANCE = new MyHandler();再传进去——这就触发复用校验，必须加注解+确保无状态 - 性能提示：共享Handler能省对象创建开销和GC压力，但收益有限；真正影响吞吐的是IO模型和编解码效率，别本末倒置去强求共享
Spring里注入@Sharable Handler要注意什么\_生命周期和作用域冲突
Spring默认单例Bean和@Sharable看似天然匹配，但有个隐藏雷：如果这个Handler被声明为@Scope("prototype")，或者被AOP代理了（比如加了@Transactional），那它就不再是原始类实例，Netty的instanceof Sharable校验会失败。
- 正确姿势：Handler类上加
@Sharable，Spring配置里用@Scope("singleton")（或不写，默认就是），且禁止任何增强代理 - 排查技巧：在
addLast()前打个断点，看传入对象的getClass().getAnnotation(Sharable.class)是否为null - 更稳妥方案：不用Spring管理Handler实例，改用工厂方法返回静态单例，彻底绕过容器代理干扰
最常被忽略的一点：@Sharable不是性能开关，而是契约声明。你声明了，就要100%守约；Netty不会帮你兜底，也不会提醒你哪里漏了状态变量——出问题时现象往往是偶发、难复现、定位成本极高。
