前言

作为互联网软件开发人员，你是不是也遇到过这样的情况？明明在代码里调用了 Thread.interrupt () 方法，想让线程停止执行，结果线程还在疯狂跑；或者用 wait () 方法等待资源时，一不注意就触发了
IllegalMonitorStateException，排查半天都找不到问题根源？

其实不止你一个人踩过这些坑。我之前在负责电商订单系统开发时，就因为没吃透 Java 线程通信的核心逻辑，线上服务出现过线程卡死的情况 —— 当时用 stop () 方法强制终止线程，导致订单数据同步一半就中断，最后花了 3 个小时才恢复数据。后来翻了无数官方文档和大厂实践案例才发现，Java 线程通信里的 interrupt ()、wait ()、notify () 这些方法，看似简单，实则藏着很多容易被忽略的细节。今天就把这些实战经验整理出来，帮你避开那些年我们都踩过的线程通信坑。

为什么 stop () 方法不能随便用？

你可能会问，既然 interrupt () 用着麻烦，那直接用 stop () 方法终止线程不行吗？毕竟写法简单，一行代码就能搞定。但实际上，从 JDK 1.2 开始，stop () 方法就被标记为 “过时” 了，阿里、字节等大厂的代码规范里更是明确禁止使用。

为什么会这样？这就要从线程安全的角度说起。当你调用 stop () 方法时，线程会立即终止，不管它当前正在执行什么操作。比如线程正在修改订单状态 —— 刚把 “待支付” 改成 “支付中”，还没来得及更新库存，就被 stop () 强制终止了，这时候就会出现数据不一致的问题。而且 stop () 方法会释放线程持有的所有锁，这些锁原本是用来保证临界区资源安全的，突然释放会导致其他线程拿到锁后，访问到不完整的中间数据，进而引发更严重的并发问题。

我之前踩过的那个坑就是典型案例：当时为了快速终止 “订单超时取消” 的监控线程，直接调用了 stop ()，结果线程终止时，正好卡在 “查询超时订单” 和 “执行取消操作” 之间，导致 12 笔超时订单既没被取消，也没继续留在待支付队列，最后还是通过日志回溯才找到这些 “消失” 的订单。所以记住，永远不要用 stop () 方法终止线程，这是保障线上服务稳定的基本要求。

interrupt () 的正确用法：它不是 “终止线程”，而是 “打个招呼”

既然 stop () 不能用，那 interrupt () 方法该怎么用才对？很多开发者误以为 interrupt () 是 “立即终止线程” 的开关，其实这是一个严重的误解 ——interrupt () 的真正作用，是给线程 “打个招呼”，告诉它 “你该准备停止了”，至于线程什么时候停止，决定权还在线程自己手里。

那具体要怎么用呢？这里分享两个实战中最常用的场景，每个场景都附上可直接复用的代码示例，你可以直接复制到项目里测试。

场景 1：中断 “可中断阻塞” 的线程

像 Thread.sleep ()、Object.wait ()、BlockingQueue.take () 这些方法，都属于 “可中断阻塞” 方法 —— 当线程正在执行这些方法时，如果调用了 interrupt ()，线程会抛出 InterruptedException 异常，并且清除 “中断状态”（也就是 isInterrupted () 方法会返回 false）。这时候我们就可以在 catch 块里处理中断逻辑，让线程优雅退出。

比如下面这个 “订单超时监控” 的线程示例，就用了 interrupt () 配合 sleep () 实现优雅终止：

public class OrderTimeoutMonitor extends Thread {
    // 标记线程是否需要运行，配合interrupt()使用
    private volatile boolean isRunning = true;

    @Override
    public void run() {
        while (isRunning) {
            try {
                // 每隔10秒查询一次超时订单（模拟可中断阻塞）
                Thread.sleep(10000);
                queryTimeoutOrders(); // 自定义查询超时订单的方法
                cancelTimeoutOrders(); // 自定义取消超时订单的方法
            } catch (InterruptedException e) {
                // 捕获到中断异常，说明需要终止线程
                System.out.println("线程收到中断信号，准备退出");
                // 重置isRunning标记，让循环退出
                isRunning = false;
                // 这里可以做一些资源清理操作，比如关闭数据库连接
                closeResources();
                // 注意：不需要再次调用interrupt()，因为异常已经清除了中断状态
            }
        }
    }

    // 对外提供的中断方法
    public void stopMonitor() {
        isRunning = false;
        this.interrupt(); // 调用interrupt()，触发sleep()抛出异常
    }

    // 以下是自定义方法，根据实际业务实现
    private void queryTimeoutOrders() {
        // 业务逻辑：查询超时未支付的订单
    }

    private void cancelTimeoutOrders() {
        // 业务逻辑：取消超时订单，恢复库存
    }

    private void closeResources() {
        // 业务逻辑：关闭数据库连接、释放线程池等
    }
}

在这个示例里，我们没有直接依赖 interrupt () 的中断状态，而是用了 volatile 修饰的 isRunning 变量做双重保障 —— 即使因为某些原因没捕获到 InterruptedException，循环也会因为 isRunning 为 false 而退出。这是大厂代码里很常见的写法，能最大限度避免线程 “卡死”。

场景 2：中断 “非阻塞” 的线程

如果线程正在执行计算型任务（比如循环处理数据），没有调用可中断阻塞方法，这时候 interrupt () 不会抛出异常，只会设置线程的 “中断状态”。这时候就需要我们在代码里主动检查中断状态，然后决定是否退出线程。

比如下面这个 “批量处理用户数据” 的线程示例：

public class UserDataProcessor extends Thread {
    private List<User> userList; // 需要处理的用户数据列表

    public UserDataProcessor(List<User> userList) {
        this.userList = userList;
    }

    @Override
    public void run() {
        for (User user : userList) {
            // 每次处理前检查中断状态，如果被中断，立即退出循环
            if (Thread.currentThread().isInterrupted()) {
                System.out.println("线程收到中断信号，停止处理数据");
                // 清理资源
                cleanUp();
                return;
            }
            // 处理用户数据（模拟计算型任务）
            processUserData(user);
        }
    }

    // 自定义数据处理方法
    private void processUserData(User user) {
        // 业务逻辑：比如更新用户等级、计算积分等
        try {
            // 模拟处理耗时
            Thread.sleep(500);
        } catch (InterruptedException e) {
            // 如果处理过程中遇到阻塞，同样需要处理中断
            System.out.println("数据处理被中断");
            // 重新设置中断状态，因为异常会清除状态
            Thread.currentThread().interrupt();
            cleanUp();
        }
    }

    private void cleanUp() {
        // 清理资源：比如关闭临时文件、释放内存等
    }
}

这里要注意一个细节：如果在 catch 块里捕获了 InterruptedException，一定要记得调用 Thread.currentThread ().interrupt () 重新设置中断状态。因为异常抛出后，JVM 会自动清除线程的中断状态，如果不重新设置，后续的 isInterrupted () 检查就会返回 false，线程可能无法正常退出。

wait () 和 notify () 的使用要点：必须和 synchronized 配合

除了线程中断，wait () 和 notify () 也是线程通信里的高频考点，同时也是最容易出错的地方。你是不是也遇到过调用 wait () 方法时，控制台抛出
IllegalMonitorStateException 的情况？其实这个错误的根源很简单 ——wait () 和 notify () 方法必须在 synchronized 同步块或同步方法里调用。

为什么会有这个限制？因为 wait () 方法的作用是让线程释放锁并进入等待状态，而 notify () 是唤醒等待锁的线程。如果不在 synchronized 块里调用，线程就没有持有锁，也就不存在 “释放锁” 的说法，JVM 为了避免这种逻辑矛盾，就会直接抛出异常。

下面用一个 “生产者 - 消费者” 模型的示例，带你看懂 wait () 和 notify () 的正确用法。这个模型在实际开发中很常用，比如 “订单生成（生产者）” 和 “订单处理（消费者）” 的解耦就会用到。

正确示例：用 wait () 和 notify () 实现生产者 - 消费者

// 订单队列（共享资源）
class OrderQueue {
    private Queue<Order> queue = new LinkedList<>();
    // 队列最大容量，避免内存溢出
    private static final int MAX_SIZE = 10;

    // 生产者添加订单（同步方法，持有OrderQueue的锁）
    public synchronized void addOrder(Order order) throws InterruptedException {
        // 注意：这里要用while循环，而不是if判断
        while (queue.size() >= MAX_SIZE) {
            System.out.println("订单队列已满，生产者等待...");
            // 释放锁，进入等待状态，直到被消费者唤醒
            this.wait();
        }
        // 唤醒后添加订单
        queue.offer(order);
        System.out.println("生产者添加订单：" + order.getOrderId());
        // 唤醒等待的消费者（如果有的话）
        this.notify();
    }

    // 消费者获取订单（同步方法，持有OrderQueue的锁）
    public synchronized Order getOrder() throws InterruptedException {
        // 同样用while循环判断，避免“虚假唤醒”
        while (queue.isEmpty()) {
            System.out.println("订单队列为空，消费者等待...");
            // 释放锁，进入等待状态
            this.wait();
        }
        // 唤醒后获取订单
        Order order = queue.poll();
        System.out.println("消费者获取订单：" + order.getOrderId());
        // 唤醒等待的生产者（如果有的话）
        this.notify();
        return order;
    }
}

// 订单实体类
class Order {
    private String orderId;
    // 构造方法、getter、setter省略
    public Order(String orderId) {
        this.orderId = orderId;
    }
    public String getOrderId() {
        return orderId;
    }
}

// 生产者线程
class Producer extends Thread {
    private OrderQueue orderQueue;
    public Producer(OrderQueue orderQueue) {
        this.orderQueue = orderQueue;
    }
    @Override
    public void run() {
        for (int i = 1; i <= 15; i++) {
            try {
                // 模拟生成订单的耗时
                Thread.sleep(500);
                Order order = new Order("ORDER_" + i);
                orderQueue.addOrder(order);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

// 消费者线程
class Consumer extends Thread {
    private OrderQueue orderQueue;
    public Consumer(OrderQueue orderQueue) {
        this.orderQueue = orderQueue;
    }
    @Override
    public void run() {
        for (int i = 1; i <= 15; i++) {
            try {
                // 模拟处理订单的耗时
                Thread.sleep(1000);
                Order order = orderQueue.getOrder();
                // 处理订单（业务逻辑省略）
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

// 测试类
public class ThreadCommunicationTest {
    public static void main(String[] args) {
        OrderQueue orderQueue = new OrderQueue();
        // 启动1个生产者、1个消费者
        new Producer(orderQueue).start();
        new Consumer(orderQueue).start();
    }
}

在这个示例里，有两个非常关键的细节，也是很多开发者容易忽略的点：

1. 用 while 循环判断条件，而不是 if：这是为了避免 “虚假唤醒”。什么是虚假唤醒？就是线程可能会在没有被 notify () 或 notifyAll () 唤醒的情况下，突然从 wait () 状态恢复。如果用 if 判断，线程唤醒后会直接执行后续代码，而不重新检查条件 —— 比如队列已经满了，生产者却因为虚假唤醒继续添加订单，导致队列溢出。用 while 循环的话，唤醒后会再次检查条件，确保符合逻辑后才执行，从根本上避免虚假唤醒。
2. notify () 和 notifyAll () 的区别：示例里用的是 notify ()，它只会唤醒一个等待锁的线程；如果用 notifyAll ()，会唤醒所有等待锁的线程。实际开发中怎么选？如果等待的线程都是做同样的事情（比如多个消费者等待订单），用 notify () 更高效，避免不必要的线程唤醒；如果等待的线程做不同的事情（比如有的线程等队列满、有的等队列空），就需要用 notifyAll ()，确保所有相关线程都能被唤醒检查条件。

总结：3 个核心要点，帮你搞定 Java 线程通信

回顾今天讲的内容，其实 Java 线程通信的核心就 3 个要点，记住这 3 点，就能避开 80% 的坑：

1. 拒绝 stop ()，用 interrupt () 实现优雅中断：永远不要用 stop () 强制终止线程，而是通过 interrupt () 给线程发 “中断信号”，配合 isInterrupted () 检查或捕获 InterruptedException，让线程自己决定退出时机，同时用 volatile 变量做双重保障。
2. wait () 和 notify () 必须在 synchronized 块里调用：这是 JVM 的强制要求，也是避免 IllegalMonitorStateException 的关键。调用 wait () 前要先获取锁，调用后会释放锁；唤醒后要重新竞争锁，拿到锁后再继续执行。
3. 用 while 循环处理等待条件，避免虚假唤醒：不管是 wait () 前的条件判断，还是唤醒后的逻辑处理，都要用 while 循环重新检查条件，不要用 if 判断，防止线程因为虚假唤醒执行错误逻辑。

最后，想问问你在实际开发中，有没有遇到过线程通信相关的问题？比如用 interrupt () 没中断成功，或者 wait () 抛出异常的情况？欢迎在评论区分享你的踩坑经历，我们一起讨论解决方案。如果觉得这篇文章对你有帮助，也可以转发给身边做 Java 开发的同事，让大家一起避开这些线程通信的坑！