为什么Thread要接受一个Runnable对象

1. 核心设计原理

在 Java/Kotlin 的线程模型中，Thread 类和 Runnable 接口通过 组合模式 实现了职责分离：

Thread 类：负责线程的创建、管理和执行机制
Runnable 接口：定义线程实际要执行的任务逻辑

2. 源代码设计（简化版）

看看 Thread 类的核心源码（简化版）：

csharp 复制代码

public class Thread implements Runnable {
    // 关键字段：存储传入的Runnable任务
    private Runnable target;
    
    // 构造函数：接收Runnable对象
    public Thread(Runnable target) {
        this.target = target;
    }
    
    // 线程启动后实际执行的方法
    @Override
    public void run() {
        if (target != null) {
            target.run(); // 调用传入的Runnable对象的run方法
        }
    }
    
    // 启动线程的方法
    public void start() {
        // 底层调用native方法创建新线程
        start0();
    }
    
    private native void start0(); // JVM内部实现
}

3. 执行流程解析

rust 复制代码

sequenceDiagram
    participant A as 主线程
    participant T as Thread对象
    participant R as Runnable对象
    
    A->>T: new Thread(myRunnable)
    A->>T: start()
    T->>JVM: 请求创建新线程
    JVM->>新线程: 创建
    新线程->>T: 调用run()
    T->>R: run()
    R-->>新线程: 执行任务代码

4. 为什么这样设计？

这种设计有三大核心优势：

职责分离原则
- Thread 专注于线程管理（生命周期、优先级等）
- Runnable 专注于业务逻辑实现

灵活性与复用性

scss 复制代码

// 同一个任务可以被多个线程执行
val task = MyTask() // 实现Runnable

// 线程1
Thread(task).start()

// 线程2
Thread(task).start()

避免单继承限制

kotlin 复制代码

// 错误示例：无法同时继承两个类
class MyThread : Thread(), ActivityListener // 不允许！

// 正确做法：实现Runnable
class MyTask : Runnable, ActivityListener {
    override fun run() { /*...*/ }
    override fun onActivity() { /*...*/ }
}

5. 设计模式视角

这是典型的 策略模式(Strategy Pattern)：

Thread 是上下文(Context)
Runnable 是策略接口(Strategy)
MyThread 是具体策略实现(ConcreteStrategy)

6. 实际应用示例

kotlin 复制代码

// 创建不同的任务策略
val networkTask = object : Runnable {
    override fun run() { downloadFile() }
}

val dbTask = object : Runnable {
    override fun run() { processDatabase() }
}

// 使用同一个Thread类执行不同策略
Thread(networkTask).start()
Thread(dbTask).start()

7. Kotlin 的简化语法糖

Kotlin 对 Runnable 有特殊支持，可以直接使用 lambda：

scss 复制代码

// 等同于 new Runnable(){ public void run(){...} }
Thread {
    println("在Kotlin中这样更简洁！")
}.start()

总结

Thread 接受 Runnable 的设计体现了面向对象的核心原则：

组合优于继承：通过组合方式扩展功能
单一职责原则：每个类/接口只做一件事
开放封闭原则：对扩展开放，对修改封闭