线程类参与序列化会引发双重破坏：Thread不可序列化，且图形上下文绑定特定线程，跨线程反序列化将导致显存句柄错乱、绘制失败或JVM崩溃；必须禁止序列化Thread及其子类，图形上下文须声明为transient，改用指令式序列化传递纯数据。
这个问题本质是**线程类参与序列化引发的双重破坏**：一方面 Thread 类本身不可序列化，另一方面图形上下文（如 Canvas、GLContext、RenderState 等）通常绑定到特定线程（尤其是 UI 或渲染线程），一旦被错误反序列化并跨线程重建，就会导致显存句柄错乱、绘制目标丢失、状态指针悬空——表现为图形撕裂、空白画布、纹理黑块、甚至 JVM 崩溃。
明确禁止序列化 Thread 及其子类
Java 规范明确将 Thread 类标记为不可序列化（无 Serializable 接口，且含 native 资源）。任何继承自 Thread 的子类，即使手动加了 implements Serializable，在调用 ObjectOutputStream.writeObject() 时仍会在运行期抛 NotSerializableException。这不是警告，是硬性失败。
若当前图计算画布中存在类似 GraphRenderThread extends Thread 的类被放入需序列化的对象图（比如作为某个 GraphJob 的字段），必须立即移除或隔离。
- 检查所有参与图任务建模的 POJO，用 IDE 的 “Find Usages” 搜索
extends Thread或implements Runnable后又被当作数据字段使用的场景 - 确认该类是否真需要“作为状态一部分传输”——绝大多数情况下，它只是执行载体，不应进入序列化流
- 若必须保留逻辑关联，改用
transient修饰，并在readObject()中按需重建新线程（注意：不能复用原线程实例）
图形上下文必须与线程生命周期强绑定
OpenGL 上下文、Skia 渲染器、JavaFX GraphicsContext 等，本质上是 OS 级资源句柄，仅在创建它的线程上有效。反序列化后若试图在另一线程（如网络线程、计算线程）中调用 canvas.drawXXX()，会触发底层 API 的线程校验失败，轻则静默丢帧，重则触发驱动级异常，造成物理损坏（如 GPU hang、显存泄漏、上下文污染）。
- 所有图形上下文对象（
Canvas、Surface、GLContext、RenderNode等）必须声明为transient - 禁止将其作为可序列化模型的字段；应改为“按需获取”，例如通过
ThreadLocal<Canvas>或渲染线程专属的上下文管理器 - 若需跨线程传递绘图指令，只序列化纯数据（顶点数组、变换矩阵、着色器参数、路径指令），而非上下文本身
采用指令式序列化替代对象图序列化
图计算画布的核心不是“传对象”，而是“传意图”。与其尝试序列化一个包含线程、画布、监听器的复杂对象树，不如定义轻量、无状态的绘图指令协议：
- 定义
DrawCommand接口族：DrawRectCmd、DrawPathCmd、UpdateTransformCmd等 - 所有命令类实现
Serializable，且仅含基本类型、数组、枚举等安全字段（不含引用、回调、资源句柄） - 在渲染线程中统一接收指令队列，由本地上下文执行 —— 避免反序列化侵入图形栈
- 配合版本号（
serialVersionUID或协议字段version: int）支持指令格式演进
补充：运行期防护与快速止损
即便代码已修复，线上环境仍可能收到旧版序列化数据。建议增加防御性反序列化拦截：
- 自定义
ObjectInputStream子类，在resolveClass()中拦截java.lang.Thread及其子类，直接抛InvalidClassException - 对图形相关类（如
android.graphics.Canvas、javax.swing.Graphics2D）也做同类拦截，避免静默失败 - 在图计算服务入口启用 JVM 参数
-Dsun.misc.ObjectStreamClass.checkTarget=false（慎用）仅作临时兜底，长期必须靠协议治理
