开篇多线程这道坎到底卡在哪里说白了Java 多线程是每个后端开发者都要正面硬刚的话题。我见过太多人一上来就背“继承 Thread 类、实现 Runnable 接口”这两条概念笔试能默写面试能背诵但真到写代码的时候——线程顺序乱了、数据对不上、程序直接卡死问题接踵而至。这篇文章不玩虚的只围绕 Thread 和 Runnable 这两条最基础也最核心的实现路径把原理讲透、把坑点说明白最后给你一套可以直接复用的代码模板。适合刚学完 Java 语法、准备踏入并发编程门槛的读者也适合工作一两年但觉得自己线程基础不牢的开发同学。我先说个结论多线程的“实现方式”从来不是难点真正的难点是理解线程的生命周期、理解 start() 和 run() 的区别、理解多线程环境下资源共享带来的不确定性。而这篇文章的设计思路就是从这两个类的使用姿势切入一步步把背后运行的逻辑拆给你看。1. 整体设计与思路拆解为什么教程都爱讲 Thread 和 Runnable1.1 多线程到底解决了什么问题在没有多线程的年代一个程序只能从上往下顺序执行。比如你要从某个接口拉数据、解析、入库这三个步骤加起来耗时 2 秒那用户就得干等 2 秒。如果其中有一步是网络请求CPU 大部分时间都在空转等待这其实是巨大的浪费。多线程的核心价值就三个字并行化。把一个大任务拆成多个小任务同时执行让 CPU 的多个核心都忙起来让等待 I/O 的时间被其他计算填充。Java 从语言层面提供了内置的多线程支持而 Thread 类和 Runnable 接口就是这门语言最早、最基础的两扇门。1.2 为什么只讲这两条路Java 里创建线程的方式网上一搜能列出四种继承 Thread、实现 Runnable、实现 Callable、使用线程池。但拨开现象看本质前三种最终都是把任务交给 Thread 去执行线程池也不过是在 Thread 外面套了一层管理壳。所以不管后续你用 ExecutorService 还是 ForkJoinPool底层的“线程怎么跑起来”这件事仍然绕不开 Thread 和 Runnable 这对老搭档。真正理解这两条路你就理解了 Java 并发编程的地基。我甚至建议你在完全搞懂 start() 和 run() 的关系之前先不要去碰线程池——地基没打好上层越复杂越容易翻车。1.3 Thread 与 Runnable两条路的本质区别在动手写代码之前先建立一个核心认知框架。Thread 是一个类Runnable 是一个接口。Thread 类本身就实现了 Runnable 接口它内部持有一个 Runnable 类型的 target 字段run() 方法里实际调用的就是这个 target 的 run()。这个设计背后的逻辑非常优雅把“线程本身”和“线程要执行的任务”分离。维度继承 Thread实现 Runnable类与接口继承类单继承限制实现接口可多实现任务与线程的关系耦合在一起解耦任务可复用资源共享需用静态变量或额外设计天然支持多线程共享同一任务实例扩展性差好适用场景快速验证、简单演示生产环境绝大多数场景这个表格看起来很干但背后每一个差异都能展开成一段血泪史。比如“资源共享”这一点实现 Runnable 接口时多个线程可以共享同一个 Runnable 实例实例内的成员变量天然就是多线程共享的而继承 Thread 每次都要 new 一个对象如果想共享数据你只能另想办法。接下来我分别拆开讲。2. 核心细节解析与实操要点Thread 类的完整使用姿势2.1 继承 Thread 的基本写法先看最直接的代码。继承 Thread重写 run()然后调用 start()。这是我当年学多线程时写的第一段代码也是很多人初识并发编程的起点public class MyThread extends Thread { Override public void run() { System.out.println(线程运行中 Thread.currentThread().getName()); } } public class Main { public static void main(String[] args) { MyThread t1 new MyThread(); t1.start(); System.out.println(主线程结束 Thread.currentThread().getName()); } }这段代码跑起来输出的顺序不一定是“主线程结束”在前还是“线程运行中”在前。因为 t1.start() 只是告诉 JVM 去创建一条新线程新线程何时真正执行 run() 里的代码由操作系统的线程调度器决定。我第一次跑这段代码的时候傻傻地以为 start() 会立即执行 run()结果输出顺序和预想完全相反那一刻才意识到什么是“并发的不确定性”。2.2 为什么必须调 start()而不是直接调 run()这是面试高频题也是新手最容易踩的坑。如果你把上面的代码改成 t1.run()程序会在主线程里同步执行 run() 的逻辑根本不会创建新线程。run() 只是一个普通方法直接调用它等于在主线程里串行执行了一遍方法体。而 start() 做的事情远比表面看起来多它会让 JVM 为线程分配栈空间、把线程状态从 NEW 变成 RUNNABLE然后等待操作系统调度。一旦进入运行状态JVM 才会回调 run() 方法。所以 start() 只能调用一次第二次调用会抛 IllegalThreadStateException因为线程已经进入过就绪状态了。Thread t new MyThread(); t.start(); t.start(); // 这里会抛出 IllegalThreadStateException这个异常的底层原因是源码里有一个threadStatus ! 0的判断。记住这个机制面试时如果能顺手说出“start() 底层会调用 native 方法 start0()由 JVM 去创建操作系统线程”基本就能拉开差距。2.3 继承 Thread 的三个已知弊端先说单继承限制。Java 类只能继承一个父类一旦你的类继承了 Thread它就不能再继承其他业务基类。我接手过一个老项目里面自定义了一个 BaseService 存放公共方法结果有个同事为了让类变成线程直接 extends Thread导致 BaseService 里的公共逻辑全部无法复用最后只能重构。这种设计在真实项目里真的很拧巴。再说任务与线程的耦合。继承 Thread 意味着一个类只能表达一种任务逻辑如果系统里有三种不同的任务你就得写三个类。而且每个任务都对应一个 Thread 对象任务本身不能被复用——这其实是对面向对象设计原则的破坏。第三点是资源共享麻烦。多个线程执行同一个任务时如果用继承 Thread 的方式你只能 new 多个对象可每个对象都有自己的成员变量数据根本不共享。想共享的话就得借助 static 变量或者额外写一个共享单例代码绕来绕去可读性直线下降。这些问题的答案其实就是 Runnable 接口。3. 核心步骤与关键实现Runnable 接口的正确打开方式3.1 Runnable Thread 组合模式实现 Runnable 的思路和继承 Thread 完全不同任务本身是一个独立的类线程只是“执行任务的载体”。把任务丢给线程让线程拿着这个任务去跑。public class Task implements Runnable { private int ticket 5; Override public void run() { while (ticket 0) { System.out.println(Thread.currentThread().getName() 卖票 ticket--); } } } public class Main { public static void main(String[] args) { Task task new Task(); Thread t1 new Thread(task, 窗口1); Thread t2 new Thread(task, 窗口2); t1.start(); t2.start(); } }不要被“卖票”这个烂大街的例子劝退它背后藏着一个非常重要的特性t1 和 t2 共享同一个 task 实例因此 task 里的 ticket 变量就是两个线程共享的数据。这是 Runnable 方案最大的优势也是理解线程安全问题的绝佳入口。3.2 为什么 Runnable 更符合“任务”的语义编程的本质是映射现实世界。现实世界里“任务”和“执行任务的工人”是两个独立的概念。写代码时任务类只关心业务逻辑不关心谁去执行线程类只关心如何调度资源不关心任务的具体内容。二者通过 Runnable 接口这个契约组合在一起各司其职。从设计角度说实现 Runnable 的类依然可以继承其他类、实现其他接口扩展性完全不受影响。从代码复用角度说同一个 Runnable 任务对象可以传给多个 Thread也可以配合线程池反复提交执行。所以 Runnable 才是生产环境里更优雅的选择这几乎没什么争议。3.3 新手的进阶方向Lambda 表达式与匿名内部类Java 8 之后Runnable 接口作为函数式接口可以直接用 Lambda 表达式简化书写。这一段很多人略过了但我觉得必须单独讲一讲因为你在阅读现代项目代码时会大量见到这种写法Thread t1 new Thread(() - { System.out.println(Lambda 线程 Thread.currentThread().getName()); }); t1.start();原理很简单Runnable 只有一个抽象方法 run()Lambda 表达式的函数体本质上就是 run() 的实现。匿名内部类的方式则更“啰嗦”一些Thread t2 new Thread(new Runnable() { Override public void run() { System.out.println(匿名内部类线程 Thread.currentThread().getName()); } }); t2.start();我建议新手从匿名内部类的写法开始理解因为它的结构最直白能看到接口方法的完整实现形态。理解了以后再切换到 Lambda你会发现整个代码量减少一半阅读体验也更好。3.4 Thread 的构造器与常用方法解析Thread 类提供了多个构造器最常用的四个是构造器说明Thread()空构造器需在子类中重写 run()Thread(Runnable target)传入任务对象target 不能为 nullThread(String name)指定线程名Thread(Runnable target, String name)同时指定任务和线程名给线程起名字不是可有可无的操作。真实项目的日志里如果全是 Thread-0、Thread-1出问题的时候靠线程名根本无法定位是哪条业务线程出了问题。我在公司里定过一条规矩所有自定义线程必须显式命名这个习惯后来帮我们排查过好几次线上问题。还有一些常用方法面试和实战都躲不开sleep(long millis)休眠当前线程单位毫秒会让出 CPU 但不释放锁join()等待调用它的线程死亡常用于主线程等待子线程完成getName() / setName()获取/设置线程名isAlive()判断线程是否存活currentThread()静态方法获取当前正在执行代码的线程对象4. 实操过程与完整复现一套代码同时演示两种线程4.1 实操目标与前置准备我用一个模拟下载任务的例子完整演示 Thread 和 Runnable 两种实现并把运行时的行为差异直白展示出来。前置环境只需要 JDK 8 及以上版本和任意 IDE不需要额外依赖。下载任务的语义是每个下载任务文件大小不同下载耗时也不同。我们用 sleep() 模拟耗时用日志模拟进度输出。这个例子比较贴近真实业务——文件下载、数据拉取这类场景天生适合并发。4.2 完整代码继承 Thread 的方案class DownloadThread extends Thread { private String fileName; private int fileSize; public DownloadThread(String fileName, int fileSize) { super(fileName 下载线程); this.fileName fileName; this.fileSize fileSize; } Override public void run() { for (int i 1; i fileSize; i) { try { Thread.sleep(200); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println(getName() 进度 (i * 100 / fileSize) %); } System.out.println(getName() 下载完成); } } public class ThreadDemo { public static void main(String[] args) throws InterruptedException { DownloadThread t1 new DownloadThread(安装包, 3); DownloadThread t2 new DownloadThread(素材包, 5); t1.start(); t2.start(); t1.join(); t2.join(); System.out.println(所有下载任务完成); } }注意我在 run() 里调用了 getName()。因为 DownloadThread 本身就是 Thread 的子类getName() 是直接从父类继承的方法写起来很自然。这里有一个非常重要的细节sleep(200) 模拟的是文件下载到每个百分点的耗时而不是整个文件的总耗时。4.3 完整代码实现 Runnable 的方案接下来是 Runnable 的版本我把任务和线程彻底分开class DownloadTask implements Runnable { private String fileName; private int fileSize; public DownloadTask(String fileName, int fileSize) { this.fileName fileName; this.fileSize fileSize; } Override public void run() { for (int i 1; i fileSize; i) { try { Thread.sleep(150); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println(Thread.currentThread().getName() 正在下载 fileName 进度 (i * 100 / fileSize) %); } System.out.println(Thread.currentThread().getName() 下载 fileName 完成); } } public class RunnableDemo { public static void main(String[] args) throws InterruptedException { DownloadTask task1 new DownloadTask(安装包, 3); DownloadTask task2 new DownloadTask(素材包, 5); Thread t1 new Thread(task1, System-Download-Module); Thread t2 new Thread(task2, Asset-Download-Module); t1.start(); t2.start(); t1.join(); t2.join(); System.out.println(所有下载任务完成线程名 Thread.currentThread().getName()); } }这段代码里我刻意用了不同的 sleep 时长和不同的打印格式目的不是炫技而是让你直观看到不同实现方式下的线程调度行为是相同的差异只在代码组织方式上。Runnable 版把“下载什么”交给了任务对象把“用什么线程名”交给了 Thread 构造器职责边界非常清晰。4.4 运行结果解读与调度规律观察跑一次 RunnableDemo输出大概率是这个样子顺序每次都不同System-Download-Module 正在下载 安装包进度33% Asset-Download-Module 正在下载 素材包进度20% Asset-Download-Module 正在下载 素材包进度40% System-Download-Module 正在下载 安装包进度66% Asset-Download-Module 正在下载 素材包进度60% System-Download-Module 正在下载 安装包进度100% Asset-Download-Module 正在下载 素材包进度80% System-Download-Module 下载 安装包 完成 Asset-Download-Module 正在下载 素材包进度100% Asset-Download-Module 下载 素材包 完成 所有下载任务完成从这个输出能看出两个规律。第一两个线程是交错执行的但交错的方式并不规律因为操作系统的线程调度器采用抢占式调度每个线程运行一个时间片后就会被切换出去。第二总耗时不是两个任务耗时的简单相加整体上接近耗时较长的那个任务——这就是并发的收益。如果你想深刻感受“并发不确定性”把这段代码连续运行十次每次的输出顺序都会不一样。这是多线程程序调试困难的根本原因你无法用“执行顺序”来推断程序状态只能依据“约束条件”来保证正确性。4.5 参数选择的背后逻辑为什么 sleep 用毫秒而不是直接计算可能有人会问模拟耗时为什么用 Thread.sleep(150) 而不是 System.currentTimeMillis() 差值sleep() 有一个硬核特性它会强制当前线程进入 TIMED_WAITING 状态主动让出 CPU 时间片。而时间差值计算不会让出 CPU两个线程仍然可能在同一个核心上抢时间片。用 sleep() 才能更真实地模拟 I/O 型任务的阻塞等待也让线程调度的交错现象更加明显。sleep 还有一个值得注意的细节它会抛出 InterruptedException这是一个受检异常编译器强制你处理。这个异常的设计初衷是当一个线程在睡眠时其他线程可以调用它的 interrupt() 方法打断它。你捕获到这个异常后通常的做法是重新设置中断标记或者直接退出任务。try { Thread.sleep(150); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return; }这个写法是我踩过坑后才养成的习惯。如果捕获了 InterruptedException 却不做任何处理直接忽略那么线程的中断状态会被清除外部代码调用 isInterrupted() 就永远返回 false整个中断机制就形同虚设了。5. 常见问题与排查技巧实录那些年我踩过的线程坑5.1 坑一线程安全没想清楚共享数据错乱Runnable 方案里共享实例成员变量是很方便的但方便也意味着危险。回到前面卖票的例子当两个线程同时执行 ticket-- 时这个操作并不是原子的——它实际上分成了“读取旧值、计算新值、写回内存”三步。两个线程可能同时读到 5然后各自减 1 写成 4导致卖出的票数和预期对不上。解决思路有两条。第一用 synchronized 关键字给共享数据的操作加锁保证同一个时刻只有一个线程执行这段代码第二使用 AtomicInteger 这类原子类把“检查-修改”包装成原子操作。我这里只强调思路具体语法不是本文重点但你一定要知道共享可变数据是线程不安全的根源。我在实际项目里定过一条纪律优先设计成“任务内部无共享可变状态”也就是每个线程只操作自己的局部变量实在需要共享再考虑用锁或线程安全的容器。这个原则要是早理解三年我能少改不少 bug。5.2 坑二join() 用不好主线程跑得太快新手写完多线程代码经常发现主线程的输出跑到子线程前面去了然后就困惑“我的线程没生效吗”。原因就是主线程和子线程是并发执行的主线程运行速度快可能早早就执行完了。如果你希望主线程等待某些子线程全部执行完再继续必须调用 join()。Thread t1 new Thread(() - System.out.println(子线程)); t1.start(); t1.join(); // 等待 t1 终止 System.out.println(主线程);join() 本质上也是利用 wait/notify 机制实现阻塞等待。它有一个重载版本 join(long millis)只等待指定毫秒数。注意如果不设置超时时间并且子线程迟迟不结束主线程会一直阻塞下去这在生产环境里是好是坏要结合业务判断。5.3 坑三栈帧中的线程安全问题没分清很多新手分不清“局部变量是否线程安全”。我直接给结论方法内的局部变量永远是线程安全的因为每个线程都有独立的虚拟机栈局部变量存在各自线程的栈帧里互不可见。只有实例变量和静态变量才存在共享风险。这个结论可以用一段简单代码验证public void work() { int localCount 0; localCount; System.out.println(localCount); }如果有五个线程同时执行 work()它们各自打印出的 localCount 都是 1不会互相覆盖。而一旦把 localCount 从局部变量改成成员变量结果就会开始乱套。理解这一点你在设计任务类的时候就知道哪些东西可以放心写在方法里哪些必须加锁。5.4 坑四死锁——两个线程互相等待对方释放锁死锁是线程进阶路上一定会遇到的经典坑这里先剧透一个最简单的模型。线程 A 持有锁 1等待锁 2线程 B 持有锁 2等待锁 1。两个线程都互不相让程序就永远卡死了。死锁的排查手段我首推 jstack 工具。先用 jps 找到进程号然后执行jstack 进程号JVM 会直接打印出检测到的死锁信息明确告诉你是哪些线程、持有哪些锁、阻塞在哪里。我处理线上问题时的经验是把 jstack 输出保存下来搜索 “deadlock” 或者 “waiting to lock” 关键字大部分问题都能一眼定位。5.5 坑五后台线程与守护线程的误解Thread 类有一个 setDaemon(boolean) 方法用来设置守护线程。守护线程有一个特性当 JVM 中所有的非守护线程都结束时守护线程会被强制终止。GC 线程就是典型的守护线程。注意一个容易出错的点setDaemon(true) 必须在 start() 之前调用否则会抛出 IllegalThreadStateException。这个设计合理的解释是线程一旦启动它的生命周期已经进入 JVM 的管理体系此时再改变它是否守护的身份会造成不可预期的行为。5.6 问题排查速查表现象可能原因排查方向线程里的逻辑没执行只调用了 run() 没调 start()检查调用的是 run 还是 start调用 start() 报 IllegalThreadStateExceptionstart() 被调用两次检查线程是否已经启动过主线程结束早子线程没跑完主线程未调用 join()检查是否需要等待子线程多线程修改共享变量结果不对缺少同步机制检查共享数据的线程安全性程序卡住不动CPU 飙升可能死锁或自旋等待用 jstack 抓取线程栈分析线程名都是 Thread-0/1 难定位创建时未指定名称显式传入线程名6. 从 Thread/Runnable 到线程池与 Callable 的自然过渡6.1 为什么生产环境很少直接 new Thread看到这里你可能产生一个疑问既然 Thread 和 Runnable 这么重要为什么真实业务中很少看到 new Thread 的代码因为直接创建线程有两个成本问题。线程的创建和销毁是有开销的包括分配栈空间、与操作系统交互、初始化线程对象等。如果业务频繁创建线程开销会被放大。另一个问题是线程数量不可控如果每来一个请求就 new 一个线程高并发下线程数量会爆炸内存直接被耗尽。所以生产环境更多是使用线程池线程池的本质就是“提前创建一批线程并复用”。但线程池内部的 worker 线程本质上仍然是 Thread 对象它执行的任务仍然是 Runnable 或 Callable。你现在打下的基础到了线程池阶段仍然完全适用。6.2 从 Runnable 到 Callable 的进化逻辑如果你已经掌握了 Runnable理解 Callable 就非常简单。Runnable 的 run() 方法没有返回值也不能抛出受检异常Callable 的 call() 方法可以返回结果可以抛出异常。它们的对应关系是// Runnable 形式 public interface Runnable { void run(); } // Callable 形式 public interface CallableV { V call() throws Exception; }Callable 配合 FutureTask 或者线程池的 submit() 方法可以拿到异步执行的结果。当任务需要返回计算结果时就必须用 Callable反之如果是“通知、打印、上报”这类只管执行的任务用 Runnable 就够了。6.3 新项目中的最佳实践建议我给正处于学习阶段的读者的建议是分三步走。第一阶段在你自己的电脑上把本文的代码全部敲一遍包括错误版本和正确版本亲眼看看直接调 run() 和调 start() 的区别。第二阶段用 Runnable 写一个稍微复杂一点的小项目比如模拟多窗口售票或者并行下载把同步机制加进去观察加锁前后数据结果的变化。第三阶段再去研究线程池和 Callable这时你会发现自己进入并发编程的大门要比想象中轻松得多。这里分享一个我自己带人时的真实习惯我会让新人先交一份“故意写错”的代码也就是从例子里去掉 join()、去掉锁、把 start() 换成 run()然后让他把自己的错误版本跑一遍。这个逆向训练的效果比直接给正确代码要好得多。因为多线程的很多原理你不亲眼看到错误发生就永远停留在“好像懂了”的层面。结尾给你留一个必须自己动手做的实验这篇文章的最后我不打算总结什么宏大结论只给你留一个我自己当年做过、受益很大的小实验。把本文的 RunnableDemo 复制到你的 IDE 里创建三个不同的 DownloadTask 实例分别放到三个线程里跑同时给这三个线程设置不同长度的时间片比如让其中一个线程任务特别大。然后反复运行五次每跑一次记录一下输出顺序。做完这个实验你会惊讶地发现每次输出顺序都不一样甚至某个线程在某一轮里跑得特别快、在下一轮却慢吞吞。这个现象背后的原因就是操作系统对线程的时间片调度和 CPU 核心分配的不完全确定性。理解了这一点你以后遇到任何多线程相关的疑难杂症心里都会先有一根弦这不是代码逻辑本身的确定性错误而是实时调度引发的状态竞态。我个人在实际开发中的体会是多线程入门阶段最重要的不是背 API而是建立起“线程是并发执行、顺序不可依赖、共享必须同步”这三个基本意识和“凡事多跑几遍、多看几眼运行结果”的实证精神。做到这几点Thread 和 Runnable 就不再是面试题里的两个名词而是你工具箱里真正顺手的两件工具。
