继承thread类不影响双亲委派机制；类加载由首次主动使用触发，严格遵循bootstrap→platform→system委托链；真正影响委派的是线程上下文类加载器的显式设置。
继承 Thread 类本身不会直接影响类加载器的双亲委派机制。
类加载发生在实例化/首次主动使用时，与继承关系无关
Java 中类的加载时机取决于“是否首次主动使用”，比如：
- 调用 new MyThread()
- 访问 MyThread 的静态字段或静态方法
- 执行 Class.forName("MyThread")
这些行为触发的是 MyThread.class 的加载，而加载过程严格遵循双亲委派：由当前线程的上下文类加载器（或默认系统类加载器）发起，逐级向上委托，最终由 Bootstrap → Platform → System 加载器尝试加载。
继承 Thread 只是让 MyThread 成为 java.lang.Thread 的子类，而 Thread 本身由 Bootstrap ClassLoader 加载（Thread.class.getClassLoader() == null），这不会改变 MyThread 的加载路径或委派逻辑。
真正产生影响的是线程上下文类加载器（ContextClassLoader）
虽然继承不破坏委派，但 Thread 提供了关键入口：thread.setContextClassLoader(customLoader)
这个设置不会改变 Thread 类自身的加载方式，但它会影响该线程中后续通过 Thread.currentThread().getContextClassLoader() 获取并使用的类加载器——例如在框架（如 JDBC、JNDI、Tomcat）中，常通过上下文类加载器去加载业务方提供的实现类。
典型场景：
- JDBC 驱动注册依赖 ServiceLoader.load(Driver.class)，它内部使用 Thread.currentThread().getContextClassLoader()；
- 若未显式设置，上下文加载器默认等于创建线程时的系统类加载器（AppClassLoader）；
- 若在 Web 应用中由 Tomcat 创建线程并设置了自定义加载器，则驱动类将由该加载器加载，绕过 AppClassLoader 的双亲委派链——这是“破坏委派”的常见方式，但根源是上下文加载器的显式切换，而非继承 Thread 这一动作。
自定义 Thread 子类时需注意 findClass 的覆盖风险
如果在 MyThread 中嵌套定义了自定义类加载器，并错误地重写了 loadClass() 方法（而非仅覆盖 findClass()），就可能中断双亲委派流程。例如：
- 错误写法：在自定义加载器里直接重写
loadClass()并跳过super.loadClass()调用 - 后果：导致核心类（如
Object、String）无法被 Bootstrap 加载，引发LinkageError或NoClassDefFoundError - 正确做法：只覆盖
findClass()，让loadClass()保持原生委派逻辑
这种风险与是否继承 Thread 无必然联系，但实践中常出现在需要动态加载任务类的线程实现中（如 WorkerThread），此时容易因逻辑耦合而误操作。
总结：继承只是语法关系，委派由加载行为和加载器实例决定
Thread 是一个普通 Java 类，它的子类加载仍走标准流程。双亲委派是否被打破，取决于：
- 类加载请求由哪个 ClassLoader 实例发起（如 AppClassLoader、自定义加载器）
- 该实例是否遵守 loadClass() 的委派约定
- 是否通过 setContextClassLoader() 主动引入非标准加载路径
继承 Thread 不自动引入新加载器，也不修改任何加载器的 parent 引用或委派逻辑。它只是让对象具备线程能力，真正的类加载控制权始终在 ClassLoader 层。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
