Thread子类属性覆盖本身非线程安全问题根源，而是易掩盖共享实例变量、误认字段线程私有等真问题；关键在变量归属与共享范围混淆，应避免用继承管理状态，优先用Runnable+ThreadLocal或ExecutorService。
多级继承体系下 Thread 子类的属性覆盖，本身不是线程安全问题的直接来源，而是容易掩盖真正的问题——比如多个线程共享了本该隔离的实例变量、或误以为子类字段天然线程私有。关键不在“继承层级”，而在“变量归属”和“共享范围”的混淆。
Thread 子类的字段默认不线程安全
即使你写了一个 GrandChildThread extends ChildThread extends Thread，只要字段是实例变量（非 static），每个线程对象确实拥有自己的一份副本——但这只对“该线程对象自身”成立。一旦多个线程共用同一个子类实例（例如反复调用 start() 后又复用对象），或通过外部引用意外共享了该实例，字段就可能被并发读写。
- Thread 对象不可重复 start()，但开发者有时会误在循环中复用同一个子类实例，导致 IllegalStateException 或逻辑错乱
- 若子类中定义了
public或protected实例字段，且父类/子类方法未加同步，其他线程通过反射或继承链访问时可能破坏状态 - 常见陷阱：在 run() 中修改实例字段，同时主线程或其他线程又调用子类提供的 getter/setter —— 没有同步机制，就是典型的竞态条件
避免用继承 Thread 管理共享状态
Thread 子类应专注“执行逻辑”，而非“承载数据”。把业务状态塞进 Thread 实例里，会让职责混乱，也违背面向对象设计原则。
- 把需跨方法传递的数据封装成独立 POJO，通过构造器注入到 Runnable 或 Thread 子类中
- 若必须在线程内维护上下文，优先使用
ThreadLocal<T>，它天然绑定当前线程，无需担心继承层级干扰 - 禁止在 Thread 子类中定义 static 可变字段来模拟“线程间共享状态”——这反而制造全局竞争点
多级继承时字段遮蔽（field hiding）的风险
当子类声明了与父类同名的实例字段（如父类有 int count，子类又写 int count），Java 允许，但这会造成字段遮蔽：子类 run() 方法访问的是自己的 count，而父类方法访问的是父类的 count。如果父类方法参与逻辑流转，极易引发状态不一致。
- 编译器不会报错，运行时行为难以追踪
- 尤其在重写父类模板方法（如
beforeRun()/afterRun()）时，父子字段不同步会导致计数错位、标志失效等隐蔽 bug - 解决方案：统一用
private字段 +protected finalgetter；或彻底避免同名字段，改用语义明确的命名（如childStepCount）
更现代、更安全的替代路径
Java 5+ 提供了比继承 Thread 更清晰、更可控的抽象方式，能自然规避继承体系带来的歧义。
- 用
Runnable或Callable<T>封装任务逻辑，把状态作为闭包变量或构造参数传入 —— 职责单一，测试友好 - 配合
ExecutorService提交任务，线程生命周期由池统一管理，避免手动 new/start 的易错操作 - 需要线程局部状态时，直接使用
ThreadLocal.withInitial(() -> new Context())，初始化逻辑清晰，且可配合try-finally或AutoCloseable确保清理
