1. 一个计时器为什么是Thread学习最好的综合演练场做Java开发的人应该都有这种感觉Thread这一章单独学Thread类、Runnable接口、synchronized、wait/notify的时候每个知识点都觉得自己懂了可是真要把它们串在一起解决一个实际问题脑子里又瞬间空白。我入行第四年的时候带过一批新人每次问他们多线程学了什么得到的回答几乎都是我会new Thread、会用线程池、知道sleep和wait的区别。但再往下问一句如果让你用线程做一个倒计时器该怎么做大部分人都会哑火。不是他们笨而是教材和视频把知识点都切碎了缺少一个能把Thread、锁、中断、状态控制、线程通信串起来的一体化案例。这其实就是JAVA进阶 THREAD学习系列最适合安排一个多线程案例的原因。计时器这个需求看起来简单——不就是每秒走一格嘛——但它天然涉及线程生命周期管理、生产者消费者模型、线程间通信、中断响应、共享变量的可见性、时间校准这一整套问题。一个计时器写好了你对Thread的理解深度完全不亚于啃完三章理论。这期笔记我就拿一个完整的多线程计时器作为例子从第一版能跑的代码开始一步步重构到相对可靠的状态。每一版都会说明当时是怎么想的、为什么这么改、以及踩了哪些坑。目标是让你看完之后不仅能自己写出一个计时器更能把这个案例里的思路移植到工作里的其他多线程场景。2. 第一版能跑的计时器显式创建线程和sleep的局限2.1 最直觉的做法主线程里死循环加sleep很多人的第一反应是这有什么难的不就while(true) { Thread.sleep(1000); second; }吗确实如果你只想要一个控制台里每秒跳动一次的数字最朴素的写法就是public class NormalTimer { public static void main(String[] args) throws InterruptedException { int second 0; while (true) { Thread.sleep(1000); second; System.out.println(已过去 second 秒); } } }这段代码能跑但有一个很致命的问题整个进程被这一个循环占死了。你想在计时的时候同时做点别的事比如按个键停止、让另一个线程去打印日志做不到因为主线程一直在循环里。更准确地说这不是多线程案例这连单线程都算不上它是串行逻辑。我当时在思考笔记结构时特别强调要用多线程案例来串联知识点就是因为计时器如果只做到这个程度它根本没有触及Thread学习的核心——多个线程并发地协作完成一件更大的事。2.2 第一版真正的多线程写法一个专职线程负责计时正确的第一版至少要让计时逻辑脱离主线程。给计时器单独开一个线程主线程在这段时间里可以做别的事情这是理解线程是独立执行流的第一步。public class SimpleThreadTimer { public static void main(String[] args) throws InterruptedException { Thread timerThread new Thread(() - { int second 0; while (true) { try { Thread.sleep(1000); } catch (InterruptedException e) { System.out.println(计时线程被中断停止计时); break; } second; System.out.println(已过去 second 秒); } }); timerThread.start(); // 主线程做自己的事情 for (int i 0; i 10; i) { Thread.sleep(2000); System.out.println(主线程还在干活这是第 (i 1) 次汇报); } } }这里有个很关键的点相信很多初学的人在这里栽过跟头为什么是timerThread.start()而不是timerThread.run()run()方法本身不创建新线程它只会在当前线程里同步执行效果跟普通方法调用一样。只有start()才是真正向操作系统申请创建一个新的执行流。如果你在main线程里直接调run()那计时器还是占着主线程之前的问题依然存在。这也是面试官极其爱问的一个基础点很多工作两三年的开发居然还答不利索。2.3Thread.sleep的局限不精确且阻塞会挡住一切第一版能跑了但继续往下想就会发现sleep的问题很大。第一Thread.sleep(1000)只是至少睡1000毫秒它不保证精确等于1000毫秒。线程醒来之后要重新参与CPU调度这中间可能有几毫秒甚至几十毫秒的误差。如果每个周期都靠sleep累计时间长了误差会越来越大别的线程也在忙的时候这个漂移尤其明显。第二sleep期间线程是阻塞的它无法执行任何代码。听起来好像没什么问题——计时器本来就要等1秒嘛——但当你想做支持暂停支持停止这些交互操作时sleep导致的阻塞就会变成一个拦路虎。你必须在另一个线程里设置标志位然后等sleep自己醒来才能读到。这就引出后面章节里的中断机制和状态控制。第一版的定位是跑通它的价值在于让你看见多线程的最基本形态独立线程、start和run的区别、sleep的基础用法以及它的局限。我们已经踩到一个很典型的坑想着计时器就是循环加延时结果把简单问题做成了串行问题。但要做一个真正称得上Java多线程案例的计时器还需要把生产者消费者的思维方式引进来。3. 核心关卡生产者-消费者模型与wait/notify机制3.1 为什么计时器天然是生产者-消费者结构如果说第一版只是一个线程在跑那这一版开始才算多线程协作。我建议先把需求拆一下一个完整可用的计时器至少要同时做两件事。计时信号产生每秒产生一次滴答展示/记录把当前的计时结果刷新到控制台或者存到某个文件里。如果这两个动作都塞给一个线程做很简单但扩展性很差。比如我想让滴答信号每100毫秒产生一次但展示端每秒才刷新一次又或者我想要两个展示端一个打印日志、一个更新图形界面。这时候生产者与消费者的模型就非常合适了——生产者负责按固定节奏产出信号消费者负责处理信号两者通过中间的缓冲/通信机制解耦。计时器生产的是秒信号一个int值消费者拿到这个值后决定怎么展示。这个模型的关键在于生产者和消费者运行在两个不同的线程里它们的节拍不一样所以必须要有一种安全的通信方式如果消费者处理得慢生产者不能覆盖掉还没处理的数据如果消费者处理得快又得等生产者产出新数据。3.2 用wait和notifyAll实现线程间协作Java里最基本的线程通信方式就是Object的wait()、notify()/notifyAll()。它们必须配合synchronized使用而且有一个极其容易出错的地方wait()会让出锁notify()不会自动让出锁。先看第一版协作的代码结构public class CooperativeTimer { private static final Object LOCK new Object(); private int seconds 0; private boolean hasNewTick false; // 生产者每秒产生一个新值 public void produce() throws InterruptedException { while (true) { Thread.sleep(1000); synchronized (LOCK) { while (hasNewTick) { LOCK.wait(); // 上一次的值还没被消费需要等待 } seconds; hasNewTick true; LOCK.notifyAll(); // 通知消费者可以取数了 } } } // 消费者拿到新值后打印 public void consume() throws InterruptedException { while (true) { synchronized (LOCK) { while (!hasNewTick) { LOCK.wait(); // 还没有新值先等着 } System.out.println(计时器当前值: seconds 秒); hasNewTick false; LOCK.notifyAll(); // 通知生产者可以继续生产了 } } } }这里面我特意写了两个while而不是if这是很有讲究的。wait()有一个经典陷阱它被唤醒时条件不一定已经满足了。因为可能有多个生产者或消费者都在等同一把锁某个线程被唤醒后抢到锁但它等待的条件可能已经被其他线程改变了。所以正确做法是唤醒后重新检查条件用while循环包住wait()而不是if判断一次就往下走。3.3 调试中遇到的诡异现象一直卡在wait按上面代码写完后我第一次跑的时候发现程序启动后控制台一动不动好像线程全部睡着了。排查了半天问题出在一个很小的细节上生产者和消费者线程的启动顺序。如果消费者先拿到锁它检查hasNewTick是false于是进入wait()并释放锁这没问题。生产者随后拿到锁生产第一个值并notifyAll此时消费者被唤醒流程正常。但反过来如果生产者先拿到锁它检查hasNewTick是false不需要等待直接生产值并notifyAll。注意这时候消费者还没有进入wait状态这个notifyAll就白发了。生产者继续下一轮循环再次获取锁时发现hasNewTick还是true进入wait()。此时消费者在另一边也会检查到hasNewTick是true会正常消费……等等那应该没问题。真正的问题发生在更极端的时序下两个线程都在等待对方的状态发生变化而唤醒信号在对方进入等待之前就已经发出去了。教科书里都教先生产后消费但真实的多线程调度完全可能打乱顺序导致的结果就是整个系统僵住。这个问题的通用解法是不要依赖唤醒信号的时序而是用状态位 循环重查来兜底。每次进入临界区都检查状态不满足就wait()被唤醒后重新检查。这本质上是一种条件变量的用法能覆盖绝大多数漏掉信号的场景。3.4 对比为什么说这个案例比单纯背锁概念有效很多初学者问过我wait和sleep到底什么区别如果只是背定义——wait释放锁sleep不释放锁——那你几分钟就背完了但根本用不出来。在这个计时器案例里你会真正体会到为什么需要wait因为我们的生产者线程和消费者线程共享同一个状态变量它们必须排队访问否则会出现数据竞争。如果直接在临界区里sleep锁会一直被持有消费者完全无法进入整个模型就退化成串行。wait的定位是让出CPU的等待它既解决了忙等浪费CPU的问题又让出了锁使另一个线程能推进。这也是面试八股文里非常常考的线程间的协作机制这一块透过计时器案例去理解它比死记硬背要牢得多。4. 从只走不停到可控暂停/停止状态标志与中断的综合运用4.1 按键暂停与启动volatile修饰的锁状态实际使用一个计时器你肯定需要暂停。暂停这件事看起来只是不再往前走但在多线程里它意味着生产者在sleep的间隙要去检查一个外部输入的状态。这个外部输入来自用户用户在另一个线程比如主线程接收键盘输入里修改状态位。于是老生常谈的问题来了多个线程同时访问一个boolean标志怎么保证一个线程改了之后另一个线程立刻可见JMMJava内存模型告诉我不加volatile的话线程可能长期读到自己工作内存里的旧值。虽然逻辑上讲sleep会触发一定的内存同步但它并不能保证可见性。所以最稳的方案是private volatile boolean paused false; private volatile boolean running true;volatile保证了对paused和running这两个字段的读写都是有主内存参与的线程间能及时看到变化。在秒信号线程里我们每隔一小段时间就检查一次public void run() { while (running) { if (paused) { // 暂停状态下尽量让出CPU减少空转 Thread.yield(); continue; } try { Thread.sleep(1000); } catch (InterruptedException e) { System.out.println(计时被外部中断); break; } seconds; System.out.println(已过去 seconds 秒); } }但这里有一个明显的缺陷如果paused期间只是yield这个线程会一直占着CPU轮询。更合理的方式是在暂停状态下等待一个继续的通知。这时候用wait/notify就更为贴切。我在实际测试中就遇到一个奇怪现象当主线程把paused设为true时计时线程居然还在输出几条秒数才停。原因很简单——计时线程当时正处在sleep(1000)之中它不可能听到你在其他线程里的修改必须等醒过来才行。这是无法立刻响应的问题无法通过volatile本身解决因为sleep会阻塞线程执行任何代码。4.2interrupt的真正作用中断阻塞的不是方法是阻塞本身前面提到的InterruptedException在这里派上了大用场。sleep被中断时会抛出InterruptedException并清空中断标志位。这意味着如果有人想在计时器走到第3秒的时候强制让它停止光靠volatile running false还不够因为计时线程还在sleep里睡觉根本看不见这个变化。必须借助interrupt()这个方法打断它的阻塞状态。我的做法是单独开一个控制线程它读取用户按键然后决定几点做Scanner scanner new Scanner(System.in); while (true) { String cmd scanner.nextLine(); if (s.equals(cmd)) { timerThread.interrupt(); // 打断 sleep让它快速响应停止 break; } else if (p.equals(cmd)) { // 设置暂停标志 } }interrupt()在语义上是请求中断一个线程它不会像stop()那样强制杀死线程而是给线程一个醒来处理中断状态的机会。这也是面试里一个经常被用来区分新旧线程控制方式的知识点stop()已经被废弃因为它会导致不可控的资源释放问题而interrupt()是协作式的线程可以选择响应也可以选择忽略。4.3 测试中发现的问题先设标志位再interrupt顺序很重要有一次我调试暂停功能时发现点了暂停之后计时器还会继续走一秒。我在控制线程里写的是paused true; // 先设暂停标志 timerThread.interrupt(); // 再中断它当前的 sleep看起来顺序没错但实际跑的时候计时线程从sleep中被interrupt唤醒立刻执行catch里的打印并break整个线程直接退出了原因在于我在catch里写的代码是统一处理——不管是停止还是暂停都当成线程退出的开始。修了两种情形暂停时先设paused true然后interrupt()。在catch中不直接退出而是回过去检查paused的值如果为true就走到continue进入暂停等待停止时把running设为false再interrupt()catch结束后while (running)循环退出。这个经验很实在多线程的异常分支不能无脑写死。你在catch (InterruptedException)里做的任何事都要先判断这次中断是什么目的。很多生产环境里线上偶现的诡异退出现象都和这类不分青红皂白统一处理中断的写法脱不开干系。4.4 生产者-消费者模型下如何塞入暂停逻辑如果沿用第三节的生产者-消费者模型暂停的位置有个微妙的抉择是暂停生产还是暂停消费从语义上讲计时器暂停时时间没有往前走所以应该暂停生产者。消费者的职责只是刷新界面可以继续阻塞等待新值。暂停生产者最干净的做法是引入一个暂停锁生产者每轮循环开头先尝试获取这个锁如果暂停了就阻塞在等待上直到控制线程释放。我在实现中就借用了最基础的公平锁方法不过Java初学阶段还是从wait/notify入手更有利于理解原理。真实的Lock体系比如ReentrantLock、AQS解决了wait/notify的很多不便之处比如可以更有针对性地做多个条件等待这也是后面学习java.util.concurrent包的埋点。计时器案例做完了之后你再去看AQS那部分源码会亲切很多因为它的Condition.await()和signal()其实和wait/notify是一个思路。5. 校准真实时间从sleep计数到绝对时间点对齐5.1 为什么sleep计数法越走越慢用sleep(1000)去做秒信号运行十分钟后你会发现计时器和真实时间对不上。原因前面已经提到sleep至少睡1000毫秒但它醒来之后能否立即拿到CPU继续执行是不确定的。如果系统负载高这个线程可能多等几十毫秒才轮到自己。每一秒都多出几毫秒累计起来十分钟可能就差掉小几百毫秒半小时可能差出去两三秒。如果你只是做个人娱乐用的小工具这点误差不算什么。但如果你要把它集成到某个监控系统里时间误差就会带来严重的问题。正确思路不该是每次睡完再1秒而是应该以真实时间为基准每次都计算距离目标时间点还差多少。5.2 基于System.currentTimeMillis()的对齐策略改进版本的核心变成这样private static final long START_TIME System.currentTimeMillis(); public void run() { while (running) { long elapsed (System.currentTimeMillis() - START_TIME) / 1000; System.out.println(计时器: elapsed 秒); // 计算下一次醒来的时刻而不是固定睡1000ms long nextWake (elapsed 1) * 1000 START_TIME; long delay nextWake - System.currentTimeMillis(); if (delay 0) { Thread.sleep(delay); } } }思路很简单先根据已经过去的真实时间算出当前秒数再算出应该醒来的绝对时间点nextWake然后用delay去睡。这样即使某一次醒晚了下一次会试图补回来而不是越差越多。我在实测中观察到一个很有意思的现象如果某次sleep醒来比预期晚了200毫秒那么下一次的打印间隔很可能明显小于1秒因为它要把之前拖延的一部分补回来。这个机制的哲学是不执着于每次睡够1秒而是执着于每次醒来的时刻要踩在整秒上。面试时如果被问到怎么做一个高精度的定时器基本思路就是这个用绝对时间点来规划下一次的唤醒时间而不是依赖固定延时叠加。5.3 暂停状态下如何保持时间正确引入暂停逻辑后对齐策略要稍作调整。暂停期间并不走时间这时候如果还是用START_TIME去算elapsed就会出现暂停60秒后一恢复计时器从恢复点又继续走还是暂停期间也计入的分歧。这里有一个小技巧暂停和恢复时各记一个时间戳暂停的总时长累加到pausedDuration变量里计算elapsed时用(当前时间 - START_TIME - pausedDuration) / 1000。保证暂停期间不会把虚拟的秒数偷偷算进去。起初我漏掉了这个细节恢复计时后发现计时器凭空多了几分钟把控制台打印翻出来对比才发现是暂停时长被混入了有效计时。那种结果根本没按预期走的排查过程虽然烦但也让我真正理解了一个道理——任何全局计时变量都必须在切换状态的瞬间考虑清楚它的基准值。6. 决定线程执行顺序的隐藏引擎优先级和调度以及那些绕不开的面试点6.1 计时器线程的优先级设置它真的有用吗Thread自带一个setPriority(int)方法范围从Thread.MIN_PRIORITY1到Thread.MAX_PRIORITY10默认是NORM_PRIORITY5。我看过不少人都以为设置高优先级就能让线程跑得更快。其实优先级只是给操作系统调度器的一个参考而且Java的线程最终映射到操作系统原生线程后优先级能不能生效、能生效到什么程度完全取决于宿主系统。在我们这个计时器场景下我给计时线程设置MAX_PRIORITY试了一版直观感受是基本没差别。因为计时器里的主要工作就是sleep和打印CPU密集度极低几乎没有和其他线程竞争的时间窗口。真正会抢CPU的是那些执行循环计算的任务优先级的发挥空间才更大。所以我对新人的建议是别把优先级当优化手段它更像调度器提示。你在简历里写掌握多线程调度不如把这章的知识讲明白面试官会更认可。6.2Thread.yield()在计时器里的正确用法前面在暂停逻辑中用到过Thread.yield()。它的语义是提示调度器当前线程愿意让出CPU让其他同优先级的线程先跑。它没有任何多少毫秒后回来的保证调度器完全可以选择忽略。在暂停场景下使用yield可以避免长时间空转占满一个CPU核心。不过更严谨的方案还是wait配合一个条件让线程真正睡过去。实践中你应该记住一个点能用阻塞等待就尽量别用自旋空转yield只适合极短的自旋等待场景。6.3 从案例延伸出去的几个高频面试考点每次做完一个案例我都会顺手把案例中牵涉到的面试高频考点梳理一遍这样复习时能快速知道这个案例除了跑通之外到底值多少分。计时器案例可以延伸出来的点大致有sleep和wait的区别是否释放锁、沉睡时间、唤醒方式。notify和notifyAll的区别只会唤醒一个还是全部什么情况下可能死锁。volatile与synchronized的边界什么时候只靠可见性就够了什么时候必须保证原子性。生产者-消费者模型能不能手写一个不依赖并发包的版本以及它的局限。线程中断机制interrupt()和InterruptedException的正确处理方式。start()与run()的区别这是Java基础面试里几乎必考的问题。这些点恰恰是一套标准的Java多线程八股文。如果只背概念很难应对追问因为面试官一个你的计时器暂停是怎么实现的就能把你问穿。把一个案例吃透比背二十个孤立的概念更有说服力。7. 完整串联最终版计时器的代码结构回顾如果把上面的优化方案都收拢到一个文件里整体结构大概是这样public class EnhancedTimer { private volatile boolean running true; private volatile boolean paused false; private final Object lock new Object(); private final long startTime System.currentTimeMillis(); private long pausedTotalDuration 0; private long pauseStartTime 0; public void togglePause() { synchronized (lock) { if (paused) { pausedTotalDuration System.currentTimeMillis() - pauseStartTime; paused false; lock.notifyAll(); } else { pauseStartTime System.currentTimeMillis(); paused true; } } } public void stop() { running false; synchronized (lock) { lock.notifyAll(); } } public void start() { Thread worker new Thread(() - { while (running) { synchronized (lock) { while (paused) { try { lock.wait(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return; } } } long elapsed (System.currentTimeMillis() - startTime - pausedTotalDuration) / 1000; System.out.println(计时器 elapsed 秒); long target (elapsed 1) * 1000 startTime pausedTotalDuration; long delay target - System.currentTimeMillis(); if (delay 0) { try { Thread.sleep(delay); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return; } } } }, timer-worker); worker.start(); } public static void main(String[] args) { EnhancedTimer timer new EnhancedTimer(); timer.start(); } }注意我最后用了Thread.currentThread().interrupt()来恢复中断标志。这是一个非常容易被忽略的细节InterruptedException被捕获时会清空中断标志。如果你在catch里直接退出那没问题但如果你后续还有其他需要根据中断标志判断的逻辑最好重新设置一下中断位否则外部代码调用isInterrupted()会拿到false造成中断状态丢失。这版代码大概不算很长但它把前面所有讨论过的知识点都装进去了绝对时间对齐、暂停锁、wait/notify、volatile、interrupt。你完全可以把它当成一个小工具拿去扩展比如加一个GUI界面、改成倒计时模式、支持多个计时器并行等。8. 从计时器案例看Java多线程学习路线下一步往哪里走我在带人的时候有一个习惯案例做完了不会马上收工而是沿着案例里的每个未充分展开的地方画一张继续深入的地图。计时器案例做完之后下一步的学习方向其实很清晰。第一站是java.util.concurrent里的ScheduledExecutorService。你会发现JDK早就帮你封装好了定时任务的能力scheduleAtFixedRate本质上就是你手动实现的那套绝对时间对齐逻辑的工业级版本。去看它的实现和我们的思路做对比会对定时任务的理解上一个台阶。第二站是ReentrantLock和Condition。wait/notify能解决的问题它们都能解决而且支持多个等待条件、支持可中断的锁获取、支持超时。从手写计时器的场景迁移到Condition你会更容易理解为什么AQS要设计等待队列。第三站是ThreadLocal。如果计时器要支持多路并发比如每个用户一个计时器你就需要一个ThreadLocal来存储各自的计数状态以免互相干扰。第四站是CompletableFuture和虚拟线程如果有条件可以了解。现如今的Java迭代速度很快但底层并行模型的思路没有变异步编排与线程协作万变不离其宗。这些知识不是孤立的它们全都能在计时器案例里找到对应的痛点。比如你一旦觉得我用notifyAll唤醒了所有线程但只想唤醒一个太浪费那就是该去学ReentrantLock的时机你觉得定时任务代码每次都要重写一遍太烦那就是该去学ScheduledExecutorService的时机。Java多线程靠看是看不会的必须靠写。计时器是我强烈推荐从0到1手写一遍的案例因为它的需求足够简单但踩坑点又足够多。把这些坑挨个踩完再来谈并发编程你的底子会扎实很多。
1. 一个计时器为什么是Thread学习最好的综合演练场做Java开发的人应该都有这种感觉Thread这一章单独学Thread类、Runnable接口、synchronized、wait/notify的时候每个知识点都觉得自己懂了可是真要把它们串在一起解决一个实际问题脑子里又瞬间空白。我入行第四年的时候带过一批新人每次问他们多线程学了什么得到的回答几乎都是我会new Thread、会用线程池、知道sleep和wait的区别。但再往下问一句如果让你用线程做一个倒计时器该怎么做大部分人都会哑火。不是他们笨而是教材和视频把知识点都切碎了缺少一个能把Thread、锁、中断、状态控制、线程通信串起来的一体化案例。这其实就是JAVA进阶 THREAD学习系列最适合安排一个多线程案例的原因。计时器这个需求看起来简单——不就是每秒走一格嘛——但它天然涉及线程生命周期管理、生产者消费者模型、线程间通信、中断响应、共享变量的可见性、时间校准这一整套问题。一个计时器写好了你对Thread的理解深度完全不亚于啃完三章理论。这期笔记我就拿一个完整的多线程计时器作为例子从第一版能跑的代码开始一步步重构到相对可靠的状态。每一版都会说明当时是怎么想的、为什么这么改、以及踩了哪些坑。目标是让你看完之后不仅能自己写出一个计时器更能把这个案例里的思路移植到工作里的其他多线程场景。2. 第一版能跑的计时器显式创建线程和sleep的局限2.1 最直觉的做法主线程里死循环加sleep很多人的第一反应是这有什么难的不就while(true) { Thread.sleep(1000); second; }吗确实如果你只想要一个控制台里每秒跳动一次的数字最朴素的写法就是public class NormalTimer { public static void main(String[] args) throws InterruptedException { int second 0; while (true) { Thread.sleep(1000); second; System.out.println(已过去 second 秒); } } }这段代码能跑但有一个很致命的问题整个进程被这一个循环占死了。你想在计时的时候同时做点别的事比如按个键停止、让另一个线程去打印日志做不到因为主线程一直在循环里。更准确地说这不是多线程案例这连单线程都算不上它是串行逻辑。我当时在思考笔记结构时特别强调要用多线程案例来串联知识点就是因为计时器如果只做到这个程度它根本没有触及Thread学习的核心——多个线程并发地协作完成一件更大的事。2.2 第一版真正的多线程写法一个专职线程负责计时正确的第一版至少要让计时逻辑脱离主线程。给计时器单独开一个线程主线程在这段时间里可以做别的事情这是理解线程是独立执行流的第一步。public class SimpleThreadTimer { public static void main(String[] args) throws InterruptedException { Thread timerThread new Thread(() - { int second 0; while (true) { try { Thread.sleep(1000); } catch (InterruptedException e) { System.out.println(计时线程被中断停止计时); break; } second; System.out.println(已过去 second 秒); } }); timerThread.start(); // 主线程做自己的事情 for (int i 0; i 10; i) { Thread.sleep(2000); System.out.println(主线程还在干活这是第 (i 1) 次汇报); } } }这里有个很关键的点相信很多初学的人在这里栽过跟头为什么是timerThread.start()而不是timerThread.run()run()方法本身不创建新线程它只会在当前线程里同步执行效果跟普通方法调用一样。只有start()才是真正向操作系统申请创建一个新的执行流。如果你在main线程里直接调run()那计时器还是占着主线程之前的问题依然存在。这也是面试官极其爱问的一个基础点很多工作两三年的开发居然还答不利索。2.3Thread.sleep的局限不精确且阻塞会挡住一切第一版能跑了但继续往下想就会发现sleep的问题很大。第一Thread.sleep(1000)只是至少睡1000毫秒它不保证精确等于1000毫秒。线程醒来之后要重新参与CPU调度这中间可能有几毫秒甚至几十毫秒的误差。如果每个周期都靠sleep累计时间长了误差会越来越大别的线程也在忙的时候这个漂移尤其明显。第二sleep期间线程是阻塞的它无法执行任何代码。听起来好像没什么问题——计时器本来就要等1秒嘛——但当你想做支持暂停支持停止这些交互操作时sleep导致的阻塞就会变成一个拦路虎。你必须在另一个线程里设置标志位然后等sleep自己醒来才能读到。这就引出后面章节里的中断机制和状态控制。第一版的定位是跑通它的价值在于让你看见多线程的最基本形态独立线程、start和run的区别、sleep的基础用法以及它的局限。我们已经踩到一个很典型的坑想着计时器就是循环加延时结果把简单问题做成了串行问题。但要做一个真正称得上Java多线程案例的计时器还需要把生产者消费者的思维方式引进来。3. 核心关卡生产者-消费者模型与wait/notify机制3.1 为什么计时器天然是生产者-消费者结构如果说第一版只是一个线程在跑那这一版开始才算多线程协作。我建议先把需求拆一下一个完整可用的计时器至少要同时做两件事。计时信号产生每秒产生一次滴答展示/记录把当前的计时结果刷新到控制台或者存到某个文件里。如果这两个动作都塞给一个线程做很简单但扩展性很差。比如我想让滴答信号每100毫秒产生一次但展示端每秒才刷新一次又或者我想要两个展示端一个打印日志、一个更新图形界面。这时候生产者与消费者的模型就非常合适了——生产者负责按固定节奏产出信号消费者负责处理信号两者通过中间的缓冲/通信机制解耦。计时器生产的是秒信号一个int值消费者拿到这个值后决定怎么展示。这个模型的关键在于生产者和消费者运行在两个不同的线程里它们的节拍不一样所以必须要有一种安全的通信方式如果消费者处理得慢生产者不能覆盖掉还没处理的数据如果消费者处理得快又得等生产者产出新数据。3.2 用wait和notifyAll实现线程间协作Java里最基本的线程通信方式就是Object的wait()、notify()/notifyAll()。它们必须配合synchronized使用而且有一个极其容易出错的地方wait()会让出锁notify()不会自动让出锁。先看第一版协作的代码结构public class CooperativeTimer { private static final Object LOCK new Object(); private int seconds 0; private boolean hasNewTick false; // 生产者每秒产生一个新值 public void produce() throws InterruptedException { while (true) { Thread.sleep(1000); synchronized (LOCK) { while (hasNewTick) { LOCK.wait(); // 上一次的值还没被消费需要等待 } seconds; hasNewTick true; LOCK.notifyAll(); // 通知消费者可以取数了 } } } // 消费者拿到新值后打印 public void consume() throws InterruptedException { while (true) { synchronized (LOCK) { while (!hasNewTick) { LOCK.wait(); // 还没有新值先等着 } System.out.println(计时器当前值: seconds 秒); hasNewTick false; LOCK.notifyAll(); // 通知生产者可以继续生产了 } } } }这里面我特意写了两个while而不是if这是很有讲究的。wait()有一个经典陷阱它被唤醒时条件不一定已经满足了。因为可能有多个生产者或消费者都在等同一把锁某个线程被唤醒后抢到锁但它等待的条件可能已经被其他线程改变了。所以正确做法是唤醒后重新检查条件用while循环包住wait()而不是if判断一次就往下走。3.3 调试中遇到的诡异现象一直卡在wait按上面代码写完后我第一次跑的时候发现程序启动后控制台一动不动好像线程全部睡着了。排查了半天问题出在一个很小的细节上生产者和消费者线程的启动顺序。如果消费者先拿到锁它检查hasNewTick是false于是进入wait()并释放锁这没问题。生产者随后拿到锁生产第一个值并notifyAll此时消费者被唤醒流程正常。但反过来如果生产者先拿到锁它检查hasNewTick是false不需要等待直接生产值并notifyAll。注意这时候消费者还没有进入wait状态这个notifyAll就白发了。生产者继续下一轮循环再次获取锁时发现hasNewTick还是true进入wait()。此时消费者在另一边也会检查到hasNewTick是true会正常消费……等等那应该没问题。真正的问题发生在更极端的时序下两个线程都在等待对方的状态发生变化而唤醒信号在对方进入等待之前就已经发出去了。教科书里都教先生产后消费但真实的多线程调度完全可能打乱顺序导致的结果就是整个系统僵住。这个问题的通用解法是不要依赖唤醒信号的时序而是用状态位 循环重查来兜底。每次进入临界区都检查状态不满足就wait()被唤醒后重新检查。这本质上是一种条件变量的用法能覆盖绝大多数漏掉信号的场景。3.4 对比为什么说这个案例比单纯背锁概念有效很多初学者问过我wait和sleep到底什么区别如果只是背定义——wait释放锁sleep不释放锁——那你几分钟就背完了但根本用不出来。在这个计时器案例里你会真正体会到为什么需要wait因为我们的生产者线程和消费者线程共享同一个状态变量它们必须排队访问否则会出现数据竞争。如果直接在临界区里sleep锁会一直被持有消费者完全无法进入整个模型就退化成串行。wait的定位是让出CPU的等待它既解决了忙等浪费CPU的问题又让出了锁使另一个线程能推进。这也是面试八股文里非常常考的线程间的协作机制这一块透过计时器案例去理解它比死记硬背要牢得多。4. 从只走不停到可控暂停/停止状态标志与中断的综合运用4.1 按键暂停与启动volatile修饰的锁状态实际使用一个计时器你肯定需要暂停。暂停这件事看起来只是不再往前走但在多线程里它意味着生产者在sleep的间隙要去检查一个外部输入的状态。这个外部输入来自用户用户在另一个线程比如主线程接收键盘输入里修改状态位。于是老生常谈的问题来了多个线程同时访问一个boolean标志怎么保证一个线程改了之后另一个线程立刻可见JMMJava内存模型告诉我不加volatile的话线程可能长期读到自己工作内存里的旧值。虽然逻辑上讲sleep会触发一定的内存同步但它并不能保证可见性。所以最稳的方案是private volatile boolean paused false; private volatile boolean running true;volatile保证了对paused和running这两个字段的读写都是有主内存参与的线程间能及时看到变化。在秒信号线程里我们每隔一小段时间就检查一次public void run() { while (running) { if (paused) { // 暂停状态下尽量让出CPU减少空转 Thread.yield(); continue; } try { Thread.sleep(1000); } catch (InterruptedException e) { System.out.println(计时被外部中断); break; } seconds; System.out.println(已过去 seconds 秒); } }但这里有一个明显的缺陷如果paused期间只是yield这个线程会一直占着CPU轮询。更合理的方式是在暂停状态下等待一个继续的通知。这时候用wait/notify就更为贴切。我在实际测试中就遇到一个奇怪现象当主线程把paused设为true时计时线程居然还在输出几条秒数才停。原因很简单——计时线程当时正处在sleep(1000)之中它不可能听到你在其他线程里的修改必须等醒过来才行。这是无法立刻响应的问题无法通过volatile本身解决因为sleep会阻塞线程执行任何代码。4.2interrupt的真正作用中断阻塞的不是方法是阻塞本身前面提到的InterruptedException在这里派上了大用场。sleep被中断时会抛出InterruptedException并清空中断标志位。这意味着如果有人想在计时器走到第3秒的时候强制让它停止光靠volatile running false还不够因为计时线程还在sleep里睡觉根本看不见这个变化。必须借助interrupt()这个方法打断它的阻塞状态。我的做法是单独开一个控制线程它读取用户按键然后决定几点做Scanner scanner new Scanner(System.in); while (true) { String cmd scanner.nextLine(); if (s.equals(cmd)) { timerThread.interrupt(); // 打断 sleep让它快速响应停止 break; } else if (p.equals(cmd)) { // 设置暂停标志 } }interrupt()在语义上是请求中断一个线程它不会像stop()那样强制杀死线程而是给线程一个醒来处理中断状态的机会。这也是面试里一个经常被用来区分新旧线程控制方式的知识点stop()已经被废弃因为它会导致不可控的资源释放问题而interrupt()是协作式的线程可以选择响应也可以选择忽略。4.3 测试中发现的问题先设标志位再interrupt顺序很重要有一次我调试暂停功能时发现点了暂停之后计时器还会继续走一秒。我在控制线程里写的是paused true; // 先设暂停标志 timerThread.interrupt(); // 再中断它当前的 sleep看起来顺序没错但实际跑的时候计时线程从sleep中被interrupt唤醒立刻执行catch里的打印并break整个线程直接退出了原因在于我在catch里写的代码是统一处理——不管是停止还是暂停都当成线程退出的开始。修了两种情形暂停时先设paused true然后interrupt()。在catch中不直接退出而是回过去检查paused的值如果为true就走到continue进入暂停等待停止时把running设为false再interrupt()catch结束后while (running)循环退出。这个经验很实在多线程的异常分支不能无脑写死。你在catch (InterruptedException)里做的任何事都要先判断这次中断是什么目的。很多生产环境里线上偶现的诡异退出现象都和这类不分青红皂白统一处理中断的写法脱不开干系。4.4 生产者-消费者模型下如何塞入暂停逻辑如果沿用第三节的生产者-消费者模型暂停的位置有个微妙的抉择是暂停生产还是暂停消费从语义上讲计时器暂停时时间没有往前走所以应该暂停生产者。消费者的职责只是刷新界面可以继续阻塞等待新值。暂停生产者最干净的做法是引入一个暂停锁生产者每轮循环开头先尝试获取这个锁如果暂停了就阻塞在等待上直到控制线程释放。我在实现中就借用了最基础的公平锁方法不过Java初学阶段还是从wait/notify入手更有利于理解原理。真实的Lock体系比如ReentrantLock、AQS解决了wait/notify的很多不便之处比如可以更有针对性地做多个条件等待这也是后面学习java.util.concurrent包的埋点。计时器案例做完了之后你再去看AQS那部分源码会亲切很多因为它的Condition.await()和signal()其实和wait/notify是一个思路。5. 校准真实时间从sleep计数到绝对时间点对齐5.1 为什么sleep计数法越走越慢用sleep(1000)去做秒信号运行十分钟后你会发现计时器和真实时间对不上。原因前面已经提到sleep至少睡1000毫秒但它醒来之后能否立即拿到CPU继续执行是不确定的。如果系统负载高这个线程可能多等几十毫秒才轮到自己。每一秒都多出几毫秒累计起来十分钟可能就差掉小几百毫秒半小时可能差出去两三秒。如果你只是做个人娱乐用的小工具这点误差不算什么。但如果你要把它集成到某个监控系统里时间误差就会带来严重的问题。正确思路不该是每次睡完再1秒而是应该以真实时间为基准每次都计算距离目标时间点还差多少。5.2 基于System.currentTimeMillis()的对齐策略改进版本的核心变成这样private static final long START_TIME System.currentTimeMillis(); public void run() { while (running) { long elapsed (System.currentTimeMillis() - START_TIME) / 1000; System.out.println(计时器: elapsed 秒); // 计算下一次醒来的时刻而不是固定睡1000ms long nextWake (elapsed 1) * 1000 START_TIME; long delay nextWake - System.currentTimeMillis(); if (delay 0) { Thread.sleep(delay); } } }思路很简单先根据已经过去的真实时间算出当前秒数再算出应该醒来的绝对时间点nextWake然后用delay去睡。这样即使某一次醒晚了下一次会试图补回来而不是越差越多。我在实测中观察到一个很有意思的现象如果某次sleep醒来比预期晚了200毫秒那么下一次的打印间隔很可能明显小于1秒因为它要把之前拖延的一部分补回来。这个机制的哲学是不执着于每次睡够1秒而是执着于每次醒来的时刻要踩在整秒上。面试时如果被问到怎么做一个高精度的定时器基本思路就是这个用绝对时间点来规划下一次的唤醒时间而不是依赖固定延时叠加。5.3 暂停状态下如何保持时间正确引入暂停逻辑后对齐策略要稍作调整。暂停期间并不走时间这时候如果还是用START_TIME去算elapsed就会出现暂停60秒后一恢复计时器从恢复点又继续走还是暂停期间也计入的分歧。这里有一个小技巧暂停和恢复时各记一个时间戳暂停的总时长累加到pausedDuration变量里计算elapsed时用(当前时间 - START_TIME - pausedDuration) / 1000。保证暂停期间不会把虚拟的秒数偷偷算进去。起初我漏掉了这个细节恢复计时后发现计时器凭空多了几分钟把控制台打印翻出来对比才发现是暂停时长被混入了有效计时。那种结果根本没按预期走的排查过程虽然烦但也让我真正理解了一个道理——任何全局计时变量都必须在切换状态的瞬间考虑清楚它的基准值。6. 决定线程执行顺序的隐藏引擎优先级和调度以及那些绕不开的面试点6.1 计时器线程的优先级设置它真的有用吗Thread自带一个setPriority(int)方法范围从Thread.MIN_PRIORITY1到Thread.MAX_PRIORITY10默认是NORM_PRIORITY5。我看过不少人都以为设置高优先级就能让线程跑得更快。其实优先级只是给操作系统调度器的一个参考而且Java的线程最终映射到操作系统原生线程后优先级能不能生效、能生效到什么程度完全取决于宿主系统。在我们这个计时器场景下我给计时线程设置MAX_PRIORITY试了一版直观感受是基本没差别。因为计时器里的主要工作就是sleep和打印CPU密集度极低几乎没有和其他线程竞争的时间窗口。真正会抢CPU的是那些执行循环计算的任务优先级的发挥空间才更大。所以我对新人的建议是别把优先级当优化手段它更像调度器提示。你在简历里写掌握多线程调度不如把这章的知识讲明白面试官会更认可。6.2Thread.yield()在计时器里的正确用法前面在暂停逻辑中用到过Thread.yield()。它的语义是提示调度器当前线程愿意让出CPU让其他同优先级的线程先跑。它没有任何多少毫秒后回来的保证调度器完全可以选择忽略。在暂停场景下使用yield可以避免长时间空转占满一个CPU核心。不过更严谨的方案还是wait配合一个条件让线程真正睡过去。实践中你应该记住一个点能用阻塞等待就尽量别用自旋空转yield只适合极短的自旋等待场景。6.3 从案例延伸出去的几个高频面试考点每次做完一个案例我都会顺手把案例中牵涉到的面试高频考点梳理一遍这样复习时能快速知道这个案例除了跑通之外到底值多少分。计时器案例可以延伸出来的点大致有sleep和wait的区别是否释放锁、沉睡时间、唤醒方式。notify和notifyAll的区别只会唤醒一个还是全部什么情况下可能死锁。volatile与synchronized的边界什么时候只靠可见性就够了什么时候必须保证原子性。生产者-消费者模型能不能手写一个不依赖并发包的版本以及它的局限。线程中断机制interrupt()和InterruptedException的正确处理方式。start()与run()的区别这是Java基础面试里几乎必考的问题。这些点恰恰是一套标准的Java多线程八股文。如果只背概念很难应对追问因为面试官一个你的计时器暂停是怎么实现的就能把你问穿。把一个案例吃透比背二十个孤立的概念更有说服力。7. 完整串联最终版计时器的代码结构回顾如果把上面的优化方案都收拢到一个文件里整体结构大概是这样public class EnhancedTimer { private volatile boolean running true; private volatile boolean paused false; private final Object lock new Object(); private final long startTime System.currentTimeMillis(); private long pausedTotalDuration 0; private long pauseStartTime 0; public void togglePause() { synchronized (lock) { if (paused) { pausedTotalDuration System.currentTimeMillis() - pauseStartTime; paused false; lock.notifyAll(); } else { pauseStartTime System.currentTimeMillis(); paused true; } } } public void stop() { running false; synchronized (lock) { lock.notifyAll(); } } public void start() { Thread worker new Thread(() - { while (running) { synchronized (lock) { while (paused) { try { lock.wait(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return; } } } long elapsed (System.currentTimeMillis() - startTime - pausedTotalDuration) / 1000; System.out.println(计时器 elapsed 秒); long target (elapsed 1) * 1000 startTime pausedTotalDuration; long delay target - System.currentTimeMillis(); if (delay 0) { try { Thread.sleep(delay); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return; } } } }, timer-worker); worker.start(); } public static void main(String[] args) { EnhancedTimer timer new EnhancedTimer(); timer.start(); } }注意我最后用了Thread.currentThread().interrupt()来恢复中断标志。这是一个非常容易被忽略的细节InterruptedException被捕获时会清空中断标志。如果你在catch里直接退出那没问题但如果你后续还有其他需要根据中断标志判断的逻辑最好重新设置一下中断位否则外部代码调用isInterrupted()会拿到false造成中断状态丢失。这版代码大概不算很长但它把前面所有讨论过的知识点都装进去了绝对时间对齐、暂停锁、wait/notify、volatile、interrupt。你完全可以把它当成一个小工具拿去扩展比如加一个GUI界面、改成倒计时模式、支持多个计时器并行等。8. 从计时器案例看Java多线程学习路线下一步往哪里走我在带人的时候有一个习惯案例做完了不会马上收工而是沿着案例里的每个未充分展开的地方画一张继续深入的地图。计时器案例做完之后下一步的学习方向其实很清晰。第一站是java.util.concurrent里的ScheduledExecutorService。你会发现JDK早就帮你封装好了定时任务的能力scheduleAtFixedRate本质上就是你手动实现的那套绝对时间对齐逻辑的工业级版本。去看它的实现和我们的思路做对比会对定时任务的理解上一个台阶。第二站是ReentrantLock和Condition。wait/notify能解决的问题它们都能解决而且支持多个等待条件、支持可中断的锁获取、支持超时。从手写计时器的场景迁移到Condition你会更容易理解为什么AQS要设计等待队列。第三站是ThreadLocal。如果计时器要支持多路并发比如每个用户一个计时器你就需要一个ThreadLocal来存储各自的计数状态以免互相干扰。第四站是CompletableFuture和虚拟线程如果有条件可以了解。现如今的Java迭代速度很快但底层并行模型的思路没有变异步编排与线程协作万变不离其宗。这些知识不是孤立的它们全都能在计时器案例里找到对应的痛点。比如你一旦觉得我用notifyAll唤醒了所有线程但只想唤醒一个太浪费那就是该去学ReentrantLock的时机你觉得定时任务代码每次都要重写一遍太烦那就是该去学ScheduledExecutorService的时机。Java多线程靠看是看不会的必须靠写。计时器是我强烈推荐从0到1手写一遍的案例因为它的需求足够简单但踩坑点又足够多。把这些坑挨个踩完再来谈并发编程你的底子会扎实很多。
