Java多线程与并发完整代码详解

一、多线程基础：优缺点与核心代价

1. 核心优点

• 资源利用率更高：CPU空闲时可调度其他线程执行，避免硬件资源浪费（比如IO等待时CPU不闲置）。

  

• 程序设计更简洁：异步场景（如文件下载、接口调用）可通过多线程拆分任务，简化复杂逻辑。

• 程序响应更快：UI界面、服务端程序可通过多线程避免主线程阻塞，提升用户或调用方的体验。

2. 主要代价（那些容易被忽略的细节）

• 设计复杂度上升：需要处理线程安全、同步、死锁、线程通信等问题，调试难度因此增加。

• 上下文切换开销：线程切换时需保存和恢复线程上下文（栈、寄存器等），这会消耗CPU资源。高频切换对性能的影响相当可观。

• 额外资源消耗：每个线程都需要占用栈内存（默认1M左右）和内核对象，线程数量过多时，内存溢出（OOM）的风险会直线上升。

二、线程创建与启动（关键细节补全）

1. 两种标准实现方式

方式1：继承Thread类

class MyThread extends Thread {
    @Override
    public void run() { 
        // 线程执行的业务逻辑（线程体）
    }
}
// 启动线程：调用start()，而非run()
new MyThread().start();

方式2：实现Runnable接口（推荐）

class MyTask implements Runnable {
    @Override
    public void run() {
        // 线程执行的业务逻辑（解耦：任务与线程分离）
    }
}
// 启动线程：将任务传入Thread实例
new Thread(new MyTask()).start();

2. 选型建议

优先选择实现Runnable接口，原因如下：

• 解耦：任务逻辑（Runnable）与线程控制（Thread）分离，便于复用和维护。

• 适配高级特性：线程池、Future等JUC工具类仅支持Runnable接口，可以降低后续的扩展成本。

• 规避单继承限制：Ja va是单继承语言，继承Thread会占用唯一的继承名额，影响类的扩展性。

3. 经典错误（务必牢记）

调用run()方法而非start()：

直接调用run()只是普通方法调用（运行在当前线程），不会启动新线程；start()才会触发JVM创建新线程，执行run()方法。

三、线程安全核心：竞态条件与临界区

1. 核心概念

• 竞态条件：多线程竞争同一共享资源时，执行结果依赖线程的执行顺序。比如多线程自增同一个变量，结果可能小于预期值。

• 临界区：导致竞态条件的代码片段，也就是多个线程共享资源并可能修改资源的代码块。

2. 本质原因

共享资源的“读-改-写”复合操作非原子性。以count++为例，它实际分为3步：读count值→自增→写回count。多线程交错执行时，数据错乱就不可避免。

四、线程安全判定：线程控制逃逸规则（重点）

核心判定原则：若一个资源（对象、文件、数据库连接等）的创建、使用、销毁，全程在同一个线程内完成，且不会逃逸到线程外部（即其他线程无法访问该资源），则该资源的使用是线程安全的。

1. 天生线程安全的场景

• 局部基本变量：存储在线程私有栈中，不共享，天然安全（比如方法内的int、boolean变量）。

• 局部对象引用（无逃逸）：对象本身在堆内存（共享区域），但引用仅存在于当前线程栈，且未通过返回值、参数传递等方式暴露给其他线程，线程安全。

2. 天生线程不安全的场景

对象成员变量存储在堆内存，多线程可通过对象引用访问并修改。若未加同步，必然存在线程安全问题。

五、不可变性与线程安全（细节补全）

• 核心结论：只读共享的资源不会产生线程安全问题；不可变对象（状态一旦创建就无法修改）天然线程安全（如String、Integer等包装类）。

• 关键提醒：不可变对象的引用不一定安全！例如：AtomicReference ref = new AtomicReference<>("a");，ref引用本身可被多线程修改（需用原子类保护），但引用指向的String对象本身不可变。

六、synchronized同步机制（核心，笔记细节补全）

synchronized是Ja va原生的悲观锁，通过“互斥”保证临界区原子性，同时保证可见性（解锁前的修改对后续加锁线程可见）和可重入性。

1. 四种作用范围（附实例与锁对象）

2. 核心特性（务必牢记）

• 可重入性：同一线程可重复获取同一把锁（如同步方法调用另一个同步方法，不会死锁）。

• 互斥性：同一时刻，仅一个线程能持有锁并进入临界区。

• 可见性：线程解锁前，对共享变量的修改会强制刷新到主内存，后续加锁线程会从主内存读取最新值。

• 非公平性：线程唤醒后会随机竞争锁，不保证请求顺序（默认非公平，性能更优）。

七、线程间通信（重点：wait/notify/notifyAll）

线程间通信的核心是“协作”（如生产者-消费者模型），常用方式包括共享对象通信、忙等待、wait/notify/notifyAll，后者是推荐做法。

1. 共享对象通信（基础）

通过共享对象的成员变量传递信号，需配合同步，避免竞态条件。例如：线程A在同步块中设置hasDataToProcess = true，线程B在同步块中读取该变量。

2. 忙等待（不推荐）

线程B循环等待信号，浪费CPU资源（空闲时也占用CPU）：

while(!sharedSignal.hasDataToProcess()){
    // 空循环，忙等待，浪费CPU
}

3. wait()、notify()、notifyAll()（核心，细节补全）

强制规则（违反会抛出IllegalMonitorStateException）

必须在synchronized同步块或方法中调用，且调用对象必须是“当前持有锁的对象”（即同步块的锁对象）。

核心机制（容易混淆的点）

• wait()：线程释放持有的锁，进入该锁的等待队列，变为非运行状态，直到被notify()或notifyAll()唤醒。

• notify()：随机唤醒等待队列中的一个线程。唤醒后需重新竞争锁，才能进入临界区。

• notifyAll()：唤醒等待队列中的所有线程。所有线程竞争锁，依次进入临界区。

关键疑问解答

问：等待线程持有锁，会阻塞唤醒线程进入同步块吗？

答：不会。线程调用wait()后，会立即释放锁，允许其他线程（包括唤醒线程）获取锁并进入同步块；唤醒线程执行完同步块、释放锁后，被唤醒的线程才会竞争锁，成功后退出wait()。

4. 常见问题与解决方案（务必牢记）

正确实现示例（避免所有问题）

public class MyWaitNotify {
    private final Object monitor = new Object(); // 唯一锁对象
    private boolean wasSignalled = false; // 保存信号，避免丢失

    // 等待信号
    public void doWait() throws InterruptedException {
        synchronized (monitor) {
            while (!wasSignalled) { // while循环，防止假唤醒
                monitor.wait();
            }
            wasSignalled = false; // 清除信号，准备下次等待
        }
    }

    // 发送信号
    public void doNotify() {
        synchronized (monitor) {
            wasSignalled = true; // 保存信号
            monitor.notify(); // 唤醒等待线程
        }
    }
}

八、死锁（核心：原因与避免）

1. 定义

两个或多个线程互相持有对方需要的锁，且永久阻塞，无法继续执行。简单说，就是线程“互相僵持”。

2. 典型场景（务必牢记）

• 基础场景：线程1锁A→等B，线程2锁B→等A，互相阻塞。

• 代码场景（TreeNode示例）：线程1调用parent.addChild(child)（锁parent），线程2调用child.setParent(parent)（锁child），后续线程1需锁child、线程2需锁parent，导致死锁。

• 数据库场景：多个事务更新相同记录，顺序相反（事务1锁记录1→等记录2，事务2锁记录2→等记录1）。

3. 死锁产生的4个必要条件（缺一不可）

• 互斥：锁资源只能被一个线程持有。

• 持有并等待：线程持有一个锁，同时等待另一个锁。

• 不可剥夺：线程持有锁时，不能被其他线程强制剥夺。

• 循环等待：多个线程形成“互相等待锁”的循环链。

4. 避免死锁的3种核心策略（重点）

策略1：固定加锁顺序（最常用、最易实现）

所有线程按相同顺序获取锁（如先锁A、再锁B），打破“循环等待”条件。

策略2：加锁时限

尝试获取锁时设置超时时间（如用Lock.tryLock(long timeout, TimeUnit unit)），超时则释放已持有锁并回退，等待随机时间后重试，打破“持有并等待”条件。

策略3：死锁检测

适用于无法固定加锁顺序、超时不可行的场景：

• 用数据结构（如Map、有向图）记录线程持有和请求的锁。

• 线程请求锁失败时，遍历锁关系图，检测是否存在循环（死锁）。

• 检测到死锁后，释放所有锁、回退重试，或按优先级让部分线程回退。

九、饥饿与公平性

1. 核心概念

• 饥饿：线程长期得不到CPU运行时间或锁资源，最终“饥饿致死”（如低优先级线程被高优先级线程长期抢占CPU）。

• 公平性：所有线程公平获取资源（按请求顺序获取），避免饥饿。

2. Ja va中导致饥饿的3个原因

• 高优先级线程吞噬低优先级线程的CPU时间（Ja va优先级1-10，优先级越高的线程被调度概率越高）。

• 线程永久阻塞在同步块外（非公平锁下，新线程可能持续抢占锁，老线程一直等待）。

• 线程等待一个永久无法完成的对象（如等待一个永远不会被notify()的对象）。

3. 实现公平性的方案

用Lock锁替代synchronized（synchronized默认非公平），自定义公平锁或使用JUC的公平锁（如ReentrantLock(true)）：

• 公平锁会维护一个等待队列，解锁后仅唤醒队列头部的线程，保证请求顺序。

• 注意：公平锁性能低于非公平锁（需要维护队列、切换线程），仅在需要避免饥饿时使用。

十、Ja va中的锁（进阶，笔记细节补全）

1. 简单锁的实现（理解原理）

核心是用“状态变量+同步”控制线程访问，示例（不可重入锁）：

public class Lock {
    private boolean isLocked = false; // 锁状态

    // 获取锁（阻塞）
    public synchronized void lock() throws InterruptedException {
        while (isLocked) { // 自旋，防止假唤醒
            wait();
        }
        isLocked = true; // 标记为锁定状态
    }

    // 释放锁
    public synchronized void unlock() {
        isLocked = false;
        notify(); // 唤醒等待线程
    }
}

2. 锁的可重入性（重点）

定义

同一线程可重复获取已持有的锁（synchronized、ReentrantLock均支持可重入），示例：

public class ReentrantDemo {
    // 两个同步方法，锁对象都是this
    public synchronized void outer() { inner(); }
    public synchronized void inner() { /* 业务逻辑 */ }
}

可重入锁的实现要点

需记录“持有锁的线程”和“重入次数”，修改后的可重入锁示例：

public class ReentrantLock {
    private boolean isLocked = false;
    private Thread lockedBy = null; // 持有锁的线程
    private int lockedCount = 0; // 重入次数

    public synchronized void lock() throws InterruptedException {
        Thread currentThread = Thread.currentThread();
        // 若锁被占用，且不是当前线程持有，阻塞
        while (isLocked && lockedBy != currentThread) {
            wait();
        }
        isLocked = true;
        lockedCount++;
        lockedBy = currentThread;
    }

    public synchronized void unlock() {
        // 仅持有锁的线程可释放
        if (Thread.currentThread() != lockedBy) {
            throw new IllegalMonitorStateException("未持有锁，无法释放");
        }
        lockedCount--;
        // 重入次数为0时，才释放锁
        if (lockedCount == 0) {
            isLocked = false;
            lockedBy = null;
            notify();
        }
    }
}

3. 关键注意点：finally中调用unlock()

用Lock锁时，临界区可能抛出异常，需要在finally中释放锁，避免锁泄露（锁永久被占用）：

lock.lock();
try {
    // 临界区（可能抛出异常）
} finally {
    lock.unlock(); // 确保无论是否异常，都释放锁
}

十一、读写锁（ReentrantReadWriteLock）

1. 核心场景

适用于“读多写少”的场景（如缓存查询、配置读取），解决“读-读互斥”的性能问题。核心原则是：

读-读共存、读-写互斥、写-写互斥。

2. 简单实现（理解原理）

public class ReadWriteLock {
    private int readers = 0; // 读线程数量
    private int writers = 0; // 写线程数量
    private int writeRequests = 0; // 写请求数量（优先写）

    // 获取读锁
    public synchronized void lockRead() throws InterruptedException {
        // 有写线程或写请求，阻塞（优先写）
        while (writers > 0 || writeRequests > 0) {
            wait();
        }
        readers++;
    }

    // 释放读锁
    public synchronized void unlockRead() {
        readers--;
        notifyAll(); // 唤醒等待的写线程
    }

    // 获取写锁
    public synchronized void lockWrite() throws InterruptedException {
        writeRequests++;
        // 有读线程或写线程，阻塞
        while (readers > 0 || writers > 0) {
            wait();
        }
        writeRequests--;
        writers++;
    }

    // 释放写锁
    public synchronized void unlockWrite() {
        writers--;
        notifyAll(); // 唤醒所有等待的读/写线程
    }
}

3. 读写锁的可重入性（笔记补全）

上述简单实现不可重入，会导致死锁（如持有写锁的线程再次请求写锁、持有读锁的线程再次请求读锁），需要优化：

• 读锁重入：用Map记录线程及读锁重入次数，已持有读锁的线程可再次获取读锁（无论是否有写请求）。

• 写锁重入：记录持有写锁的线程及重入次数，已持有写锁的线程可再次获取写锁。

• 锁降级：持有写锁的线程可直接获取读锁（无需释放写锁），避免写锁释放后被其他线程抢占。

十二、信号量（Semaphore）

1. 核心作用

控制并发线程数量（如限流、连接池控制），可以看作是“可计数的锁”。JUC中已提供ja va.util.concurrent.Semaphore，无需自定义。

2. 核心特性

• 可计数：允许同时获取多个许可（如permits=5，可同时有5个线程获取许可）。

• 有上限：可设置最大许可数（如上限10，超过则阻塞）。

• 可当作锁：当permits=1时，等价于非公平锁（控制单个线程进入临界区）。

3. 常用示例（限流）

// 上限3个线程同时执行
Semaphore semaphore = new Semaphore(3);
for (int i = 0; i < 10; i++) {
    new Thread(() -> {
        try {
            semaphore.acquire(); // 获取许可（阻塞，直到有空闲许可）
            // 临界区（如接口调用、资源操作）
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            semaphore.release(); // 释放许可
        }
    }).start();
}

十三、阻塞队列（BlockingQueue）

1. 核心区别（与普通队列）

当队列空时，获取元素（take()）会阻塞；当队列满时，添加元素（put()）会阻塞。无需手动处理线程同步，因为内部已经实现了。

2. 核心作用

实现生产者-消费者模型（解耦生产者和消费者，平衡两者速度），是线程池底层的核心组件（用于缓存任务）。

3. 简单实现（理解原理）

public class BlockingQueue {
    private final List