synchronized在Netty网关连接池中用于精准控制共享状态变更，聚焦连接句柄、待确认队列等有限资源的串行访问，按连接实例加锁、细粒度保护请求响应匹配映射，禁用全局锁与锁内阻塞操作。
在基于 Netty 的网关连接池中使用 synchronized，核心目标不是“加锁本身”，而是**精准控制共享状态的变更时机**，尤其在异步转同步、连接复用、设备响应匹配等关键路径上避免竞态。它不用于保护整个 I/O 流程（Netty 本身是线程安全的），而聚焦于连接句柄、会话标识、待确认指令队列等有限共享资源的串行访问。
连接池中的连接对象需按实例加锁
每个设备连接（如 Channel 或封装它的 DeviceConnection）应视为独立资源。对单个连接执行写操作（如下发指令）、更新其状态（如 isBusy、pendingRequestId）时，必须以该连接实例为锁对象：
- 推荐写法：
synchronized(connection) { connection.writeAndFlush(...); connection.setPendingId(id); } - 避免用
synchronized(this)或synchronized(ConnectionPool.class)—— 前者锁粒度太粗（若this是池对象，会阻塞所有连接），后者全局锁直接扼杀并发能力 - 连接对象本身要确保不可被外部替换或重置，否则锁失效
请求-响应匹配需用唯一标识+细粒度锁
因设备协议无完整事务头，需靠业务 ID（如时间戳+序列号）关联请求与回包。该 ID 映射关系（如 Map<String, CompletableFuture<?>>）是典型共享资源：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 写入待匹配表（发请求时）和读取/移除（收响应时）必须同步，但只需锁住该 Map 实例，而非整个连接或类
- 示例：
private final Map<String, CompletableFuture<Response>> pendingRequests = new ConcurrentHashMap<>();—— 此处用ConcurrentHashMap已满足大部分场景；仅当需原子性组合操作（如“先查再删再回调”）时，才用synchronized(pendingRequests)包裹 - 切忌把锁范围扩大到网络调用内部（如
synchronized {... channel.write(...).await(); ...}），这会阻塞 Netty EventLoop
静态资源初始化可使用类锁，但仅限一次
网关启动时加载的全局配置（如厂商协议解析器映射表 Map<String, ProtocolHandler>）、连接池默认参数等，在首次初始化后只读，适合用类锁保障单次安全写入：
立即学习“Java免费学习笔记（深入）”；
- 写法：
static { synchronized(DeviceGateway.class) { if (handlers == null) handlers = loadHandlers(); } } - 运行时所有连接复用该只读结构，无需再加锁
- 禁止在类锁内执行 I/O、远程调用或耗时计算，否则拖慢所有后续线程
避免锁嵌套与跨作用域持锁
网关中常见模式是“下发指令 → 等待响应 → 更新业务状态”。若将等待逻辑（如 CompletableFuture.get()）和状态更新放在同一同步块内，极易引发线程挂起并长期占用锁：
- 正确拆分：同步块仅做“存 pending + 发送”，响应处理由 Netty ChannelHandler 异步触发，再单独同步更新业务状态
- 严禁在
synchronized块中调用Thread.sleep()、Object.wait()或阻塞式数据库查询 - 锁对象尽量使用私有 final 字段（如
private final Object lock = new Object();），防止外部误锁
