Java中不可序列化对象（如Thread、Socket）须通过组合模式解耦：定义纯数据的可序列化类（如TaskSpec）仅传输重建所需元数据，或用transient+自定义readObject延迟注入资源，或采用Serializable接口+本地工厂实现行为抽象与资源解耦。
Java 中不能直接序列化 Thread、Socket、Connection 等运行时资源对象，因为它们未实现 Serializable，也不支持跨 JVM 状态迁移。所谓“通过组合模式包装不可序列化对象实现安全传输”，本质上不是让这些对象变得可序列化，而是把它们从序列化路径中剥离，只传输其可重建的意图、参数或元数据——这正是组合模式在序列化场景下的正确用法：将不可序列化的“行为载体”与可序列化的“状态描述”解耦。
用组合类封装可序列化状态，隔离不可序列化资源
定义一个轻量级、纯数据的组合类（如 TaskSpec），只包含可序列化的字段（ID、参数、超时、操作类型等），不持有任何线程、连接或句柄：
-
不这样做：
public class WorkerTask implements Serializable { private Socket socket; private Thread worker; ... }→ 必然抛NotSerializableException -
应该这样做：
public class TaskSpec implements Serializable { private String taskId; private Mapparams; private long timeoutMs; private String actionType; } - 接收方拿到
TaskSpec后，用自己的本地资源执行：executor.submit(() -> handler.execute(spec));
组合对象中显式声明 transient 并配合自定义 readObject
如果必须保留对不可序列化对象的引用（例如作为策略组件），可在组合类中将其标记为 transient，并在反序列化后主动重建：
- 声明字段：
private transient ExecutorService executor; - 重写
readObject方法，在反序列化完成后注入当前环境的实例：this.executor = GlobalExecutor.get(); - 务必同步声明
private static final long serialVersionUID = 1L;，否则自定义方法不会被调用
避免组合中隐式引入不可序列化依赖
组合类若含非静态内部类、lambda 或匿名类，可能隐式捕获外部不可序列化对象（如 this 指向含 Socket 的外层类）：
- 改用
public static class定义内部处理器，切断对外部实例的引用 - lambda 表达式中只捕获基本类型、字符串或已实现
Serializable的 DTO，避免写成() -> doWork(this.socket) - 检查所有嵌套字段类型：如
List中的Handler类也必须可序列化，否则整个组合类失效
替代方案：用接口+工厂解耦，比“包装”更安全
真正健壮的设计不依赖“包装不可序列化对象”，而是用接口抽象行为，由接收端按需创建资源：
- 定义可序列化接口：
public interface ExecutableTask extends Serializable { String getAction(); MapgetParams(); } - 发送方只传实现该接口的简单类（无任何资源字段）
- 接收方通过本地工厂映射到具体执行器：
TaskExecutorFactory.getExecutor(task.getAction()).run(task); - 这样既规避了序列化风险，又提升了扩展性和测试性
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
