Java中Thread类与Runnable接口在JVM线程调度中无实质区别，均生成java.lang.Thread实例参与OS级调度，调度权重由操作系统决定，与实现方式无关。
Java 中的 Thread 类 和 Runnable 接口 在 JVM 进程切片（即线程调度）中没有区别，也不影响调度权重。
调度权重由操作系统和JVM共同决定，与实现方式无关
JVM 本身不直接分配 CPU 时间片权重；它把线程交给底层操作系统（如 Linux 的 CFS、Windows 的优先级调度器）管理。无论线程是通过继承 Thread 类还是实现 Runnable 接口创建的，最终都表现为一个 java.lang.Thread 实例——JVM 调度器看到的只是 Thread 对象，而不是它的来源方式。
- 所有线程默认以 NORM_PRIORITY（5） 启动，可通过
setPriority(int)修改（范围 1–10），但该值仅作为 OS 调度器的参考，不保证严格映射 - Runnable 实现类被传入 Thread 构造器后，Thread 实例才真正参与调度；Runnable 本身不是线程，只是一个任务契约
- Thread 子类实例和 Runnable + Thread 组合实例，在 JVM 线程状态机（NEW → RUNNABLE → BLOCKED…）中行为完全一致
真正影响调度行为的是线程状态和系统资源竞争
调度表现差异来自运行时行为，而非编码形式：
- 频繁进入
WAITING或TIMED_WAITING（如调用wait()、sleep()、join()）会主动让出时间片 - 同步块争抢锁失败导致
BLOCKED，也会暂停调度，直到获得锁 - CPU 密集型任务若无 yield 或 sleep，可能因 OS 时间片耗尽被抢占，与 Runnable/Thread 写法无关
为什么有人误以为“Runnable 更轻量”
这种说法混淆了设计模型和运行时开销：
立即学习“Java免费学习笔记（深入）”；
- Runnable 方式确实更利于解耦、复用和资源共享（比如多个 Thread 共享同一个 Runnable 实例），但这属于架构优势，不改变线程实体的调度属性
- Thread 子类多一次继承关系，编译期有轻微字节码差异，但运行时对象头、栈空间、本地线程映射（native thread）完全相同
- JVM 对两种方式生成的线程不做任何特殊标记或分组，HotSpot 中统一使用
OSThread和JavaThread结构体管理
需要关注调度控制时，应操作 Thread 实例本身
如果你希望影响实际执行节奏，直接作用于 Thread 对象：
- 调整优先级：
t.setPriority(Thread.MAX_PRIORITY)（慎用，多数场景无效或引发饥饿） - 主动让权：
Thread.yield()提示调度器切换，但不保证立即生效 - 配合 OS 策略：在 Linux 上可结合
chrt命令设置实时调度策略（需 JNI 或外部脚本，Java 层不可控） - 避免伪共享和长临界区，减少上下文切换和锁竞争——这才是提升响应性的关键
归根结底，选 Thread 还是 Runnable，是设计选择，不是性能开关。JVM 调度器眼里只有线程，没有“出身”。
