多线程打印1~100全解法：从synchronized到CompletableFuture

如果你正在学多线程，大概率绕不开“多线程打印1~100”这道题。别小看这短短一行题目，面试官、老师、技术文章都爱拿它当试金石，因为它恰好覆盖了多线程编程最核心的三件事：临界区怎么保护、线程之间怎么协作、通知机制怎么设计。我面试候选人的时候，光看这道题就能大致判断出对方并发基础扎不扎实。

这篇文章不打算只给一个答案。我会把这道题从Java到C++、Python、Linux C，从synchronized到ReentrantLock、Semaphore、CompletableFuture完整过一遍，再把面试追问和线上排查那些坑一起讲了。适合刚接触并发编程的初学者，也适合想系统梳理多线程知识的工作两三年的开发者。你不需要一次看完，建议先把每段代码敲一遍，再回来看讲解，收获会翻倍。

1. 这道题到底在考什么——先看清题目背后的本质

1.1 题目拆解：三个隐藏考点

很多人拿到“多线程打印1~100”，第一反应是：这有什么难的？循环100次打印不就完了？但一旦加上“多线程”三个字，事情就变了。把题面翻译成技术语言，你立刻会看到三个明确的考点：

第一个是数据竞争。多个线程同时访问同一个共享变量（比如当前打印到几），如果不做同步控制，就会发生竞争。一个线程读到1，还没来得及自增，另一个线程也读到1，结果就出现了重复打印，或者跳号漏号。这不是小概率事件，在抢占式调度下，只要跑的线程够多、循环次数够大，问题必然出现。

第二个是顺序约束。如果题目要求“1、2、3、4……100”严格按顺序打印，那么线程之间不只是“别打架”这么简单，还要协调好“轮到谁打印”。这就要引入线程间通信机制，比如wait/notify、Condition、信号量，都属于这类工具。

第三个是生命周期管理。线程不能无限跑下去，打印完100以后，所有线程要能优雅退出。很多新手栽在这里：主线程提前结束了，子线程还在跑；或者子线程打印完100了还在等着被唤醒，导致程序无法退出。我见过不少人在notify、signal这块写得稀烂，最后卡死。

1.2 常见的题面变体，别把范围看窄了

在实际学习和面试中，“多线程打印1~100”通常有好几个变体，每一种考察点不一样：

第一种是不要求顺序，只要1到100不重不漏。这种题主要考原子性，最简单的做法是用AtomicInteger或者加synchronized保护自增和打印。本质上是把“读当前值 + 判断 + 打印 + 自增”这四个动作绑成一个不可分割的整体。

第二种是3个线程轮流打印，线程A打印1、4、7……，线程B打印2、5、8……，线程C打印3、6、9……。这种就要求“按余数分配”，属于比较常见的面试题。后面我会给出完整解法。

第三种是两个线程交替打印奇偶数，一个线程打印奇数，一个线程打印偶数。这个题跟第二种本质相同，都是顺序控制，只是换了个包装。

第四种是3个线程循环打印“ABC”，打印10次。有些变体会把数字变成字母，逻辑一模一样，区别只是状态判断从数字变成了模式匹配。

把这几种变体放在一起看，你就能发现：多线程打印1~100更像一个家族的“入门题”，变化无穷，核心却始终是那三个考点。你能把它吃透，后面看生产级代码里的线程协作，会容易得多。

1.3 一个容易被忽略的真相：这道题本质上是串行化的

我在这里必须先说一个反常识的结论：这道题无论你怎么优化，最终打印1到100这个动作，一定是串行的。因为屏幕输出只有一份，println本身就必须一个一个来；就算你并行打印，最终落盘或者显示的顺序也还是要靠某种机制排好。

这就带来一个问题：既然最终是串行，那为什么还要用多线程去打印？直接一个单线程for循环不香吗？

答案在于，这道题的目的不是“更快”，而是“更正确”。它是用来训练并发编程思维的最小练习。你在真实业务里写一个并发下载器、写一个Web服务器、写一个消息队列消费者，面对的问题本质上是类似的：有多个执行单元，有共享的资源，有必须遵守的协作顺序。打印1到100，只是把这些复杂问题剥掉业务外壳之后的样子。

认清这个本质对你做性能设计很重要：不要指望把这道题写得多线程化就能跑得比单线程快。真正能提升性能的地方，是让多个线程各自去并行处理互不依赖的任务，最后再把结果汇总。这也是后面第5节要展开的内容。

2. 把同步账算清楚——临界区、锁和线程协作的基本功

2.1 为什么必须加锁：i++不是原子操作

很多新手有个幻觉：i++这种一句代码，执行起来应该就是一瞬的事，不会出问题吧？实际上在CPU和编译器眼里，i++至少要拆成三步：从内存读取i的值到寄存器，在寄存器里加1，把结果写回内存。任何一步被打断，另一个线程就可能读到旧值。

我之前带过一个人，他把共享变量声明成volatile，然后用i++去实现打印自增，说“volatile不是保证可见性吗，应该没问题吧”。这正好是个经典误解。volatile只保证“一个线程修改了值，另一个线程能马上看到”，但它不保证“多个线程同时修改时不打架”。i++这种“读-改-写”操作需要的是原子性，volatile给不了，必须借助锁或者AtomicInteger这类原子类。

那为什么synchronized能解决？因为synchronized进去之后，相当于给这段代码画了一条“单行通道”，同一时刻只允许一个线程进入，其他线程在门口等着。这样“读-改-写”三步在持锁期间不会被穿插，就变成原子操作了。底层的缓存一致性协议、内存屏障这些东西，你现阶段可以略知一二，但至少要能把“锁是干什么的”讲清楚。

2.2 三种同步范式：互斥锁、条件变量与信号量

我把线程同步的工具按照使用场景分成三类，初学者把这三类分清楚，后面看什么语言都很快。

第一类是互斥锁，核心作用是“保护临界区”。这个最好理解，就像公共厕所的门锁，一个人进去把门锁上，别人只能等。Java里的synchronized、ReentrantLock，C++里的std::mutex，Python里的threading.Lock，都属于这一类。它解决的是“数据竞争”问题，不负责协调“谁先执行”。

第二类是条件变量，核心作用是“等待某个条件成立再继续”。生活化的例子是排号叫号：你拿着号在等候区坐着（wait），叫号器叫到你的号（signal），你才起来去柜台办理。Java里的wait/notify、Condition，C++里的std::condition_variable，Linux C里的pthread_cond_t，都是条件变量。它解决的是“线程间顺序协作”问题。

第三类是信号量，本质是一个计数器，允许多个线程同时访问有限资源。生活化的例子是停车场的空位指示牌：进场时空位数减1，出场时加1，空位为0时新来的车必须等待。Java里的Semaphore就是干这个的。

有了这三类工具的概念，你再看多线程打印1~100，整个思路就清晰了：保护临界区用互斥锁，控制打印顺序用条件变量，如果想实现“接力式”协作，可以用信号量。

2.3 别踩自旋的坑：何时用自旋，何时用阻塞

除了上面三种“正规军”，还有一个经常被拿来讨论的概念：自旋锁。自旋锁的特点是，线程拿不到锁的时候不睡觉，而是不断地循环尝试。

自旋的好处是省去了线程阻塞和唤醒的上下文切换开销，坏处是空转时白白消耗CPU。因此自旋适合临界区极短、锁竞争不激烈、CPU核数又比较多的场景。JVM里synchronized的锁升级就包含这个思想：先偏向锁，竞争多了变轻量级锁（自旋），再多了变重量级锁（阻塞）。

回到我们的打印题目，打印本身属于“耗时相对长”的临界区，而且线程间需要互相等待，用自旋锁反而不合适。你可能会说：我用AtomicInteger不断循环判断“轮到我了没”，这不也能实现吗？确实能，但那是“忙等待”，任何一个线程在打印的时候，其他线程都在空转，100个数打印下来，浪费的CPU时间非常可观。学到这里，你可以试着对比一下忙等待和wait/notify两种方式的CPU占用差异，这是个很有意思的动手实验。

3. Java解法实战——从synchronized到CompletableFuture

3.1 最经典的写法：synchronized + wait/notify

先给出我最推荐新手掌握的版本：三个线程轮流打印1~100。这里我统一用3个线程做示例，改线程数也非常简单。

java复制public class PrintBySync {

    private static final Object LOCK = new Object();
    private static final int LIMIT = 100;
    private static final int THREAD_COUNT = 3;
    private static int current = 1;

    public static void main(String[] args) {
        for (int t = 0; t < THREAD_COUNT; t++) {
            int id = t;
            new Thread(() -> {
                while (true) {
                    synchronized (LOCK) {
                        // 用while而不是if，防止虚假唤醒
                        while (current <= LIMIT && current % THREAD_COUNT != id) {
                            try {
                                LOCK.wait();
                            } catch (InterruptedException e) {
                                Thread.currentThread().interrupt();
                                return;
                            }
                        }
                        if (current > LIMIT) {
                            // 最后一个线程退出前，必须唤醒其他线程，否则程序卡死
                            LOCK.notifyAll();
                            break;
                        }
                        System.out.println("线程" + id + "打印: " + current);
                        current++;
                        LOCK.notifyAll();
                    }
                }
            }, "thread-" + t).start();
        }
    }
}

逐段拆解一下。最核心的是while循环里的条件判断：current <= LIMIT表示还没打印完，current % THREAD_COUNT != id表示还没轮到当前线程。两个条件同时满足，线程就进入等待。为什么要用while而不是if？因为线程被wait唤醒后，可能只是“虚假唤醒”，或者虽然轮到自己了但等它抢到锁时，又已经被别的线程处理过了。如果用if，唤醒后会继续往下走，极易出现重复打印。用while，唤醒后会重新检查一遍条件，能挡住所有这些意外。

打印完之后，必须调用notifyAll而不是notify。这是一个非常常见的坑。notify只随机唤醒一个线程，如果唤醒的是一个不该执行的线程，它检查条件不满足又去wait了，那其他真正该执行的线程就没机会被唤醒，整个程序就卡死了。notifyAll虽然会唤醒所有线程，看似浪费，但会有线程检查条件后自行继续wait，所以安全得多。最后current > LIMIT时，通知所有线程退出也是同理。

这个版本我用synchronized是因为它语法简单，不是因为它最优。它在JVM层面已经做了很多锁优化，对一个入门题目来说，性能完全够用。

3.2 更精细的ReentrantLock + Condition写法

ReentrantLock相比synchronized，最大的优势之一就是可以创建多个Condition对象。相当于把“等待队列”按照不同条件拆成了多个，可以精确唤醒某一类线程，而不是像notifyAll一样把所有人都喊起来再筛选一遍。

java复制import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.ReentrantLock;

public class PrintByCondition {

    private static final ReentrantLock LOCK = new ReentrantLock();
    private static final int LIMIT = 100;
    private static final int THREAD_COUNT = 3;
    private static final Condition[] CONDITIONS = new Condition[THREAD_COUNT];
    private static int current = 1;

    public static void main(String[] args) {
        // 注意：必须先初始化Condition，再启动线程，因为线程运行后马上要用它
        for (int i = 0; i < THREAD_COUNT; i++) {
            CONDITIONS[i] = LOCK.newCondition();
        }
        for (int t = 0; t < THREAD_COUNT; t++) {
            int id = t;
            new Thread(() -> {
                while (true) {
                    LOCK.lock();
                    try {
                        while (current <= LIMIT && current % THREAD_COUNT != id) {
                            CONDITIONS[id].await();
                        }
                        if (current > LIMIT) {
                            for (Condition c : CONDITIONS) {
                                c.signalAll();
                            }
                            break;
                        }
                        System.out.println("线程" + id + "打印: " + current);
                        current++;
                        // 精确唤醒下一个线程，比如线程0打印完唤醒线程1
                        CONDITIONS[(id + 1) % THREAD_COUNT].signal();
                    } catch (InterruptedException e) {
                        Thread.currentThread().interrupt();
                    } finally {
                        LOCK.unlock();
                    }
                }
            }, "thread-" + t).start();
        }
    }
}

这个版本最值得注意的地方有两个。一个是Condition数组必须在启动线程之前全部创建好。我见过有人把线程启动代码写在前面，结果新线程一启动就抢到锁，去访问condition的时候发现数组元素还是null，直接空指针。另一个是await和signal必须放在lock和unlock之间，因为Condition的等待和通知都依赖锁的存在，这个和Object.wait/notify必须配合synchronized是一个道理。

最后那段“退出前signalAll”也很关键。最后一个线程break之前，如果不唤醒其他线程，其他线程可能还在Condition上await，程序就会出现“打印到100了但是JVM进程不退出”的情况。

3.3 Semaphore思路：让线程按顺序接力

如果你理解了信号量，你会觉得这个题用Semaphore写起来特别直白。思路是给每个线程发一个信号量，只有拿到许可的线程才能打印。初始状态下，线程0的信号量有1个许可，线程1和线程2的信号量都是0个许可。线程0打印完释放线程1的许可，线程1打印完释放线程2的许可，依此类推，像接力棒一样传递下去。

java复制import java.util.concurrent.Semaphore;

public class PrintBySemaphore {

    private static final int LIMIT = 100;
    private static final int THREAD_COUNT = 3;
    private static final Semaphore[] SEMAPHORES = new Semaphore[THREAD_COUNT];
    private static int current = 1;

    public static void main(String[] args) throws InterruptedException {
        for (int i = 0; i < THREAD_COUNT; i++) {
            SEMAPHORES[i] = new Semaphore(i == 0 ? 1 : 0);
        }
        for (int t = 0; t < THREAD_COUNT; t++) {
            int id = t;
            new Thread(() -> {
                while (true) {
                    try {
                        SEMAPHORES[id].acquire();
                        if (current > LIMIT) {
                            releaseNext(id);
                            break;
                        }
                        System.out.println("线程" + id + "打印: " + current);
                        current++;
                        releaseNext(id);
                    } catch (InterruptedException e) {
                        Thread.currentThread().interrupt();
                        return;
                    }
                }
            }, "thread-" + t).start();
        }
    }

    private static void releaseNext(int id) {
        int next = (id + 1) % THREAD_COUNT;
        SEMAPHORES[next].release();
    }
}

这个方案的可读性很高，几乎没有复杂的等待条件判断，逻辑就是“持有许可就打印，打印完把许可传下去”。但要注意，Semaphore默认是非公平的，在高竞争下可能出现某个线程长时间抢不到许可的情况。这道题里线程数少，问题不明显，如果你写生产级代码，创建Semaphore时最好显式传入true使用公平模式。

3.4 CompletableFuture编排：异步等待任务结果

热搜词里有“java 多线程completablefuture 等待任务结果”，我单独聊聊这块。在很多业务代码里，“多线程打印1~100”会被改装成一个更实际的问题：for循环里有一批任务，我想让它们并发执行，等所有任务都执行完，拿到结果后再继续。

先看最简单的场景：在for循环里给每个数字提交一个打印任务，最后统一等待。

java复制import java.util.concurrent.CompletableFuture;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class PrintByCompletableFuture {

    public static void main(String[] args) {
        ExecutorService pool = Executors.newFixedThreadPool(4);
        CompletableFuture<?>[] futures = new CompletableFuture[100];
        for (int i = 1; i <= 100; i++) {
            int num = i;
            futures[i - 1] = CompletableFuture.runAsync(() -> {
                System.out.println(Thread.currentThread().getName() + "打印: " + num);
            }, pool);
        }
        // 等待所有任务完成，避免主线程提前退出
        CompletableFuture.allOf(futures).join();
        pool.shutdown();
    }
}

这段代码的输出顺序是不确定的，因为任务交给了线程池并行执行。但它的核心价值在于演示了CompletableFuture的典型用法：批量提交任务、统一等待所有结果。如果你要等待每个任务的返回值，可以改成supplyAsync，然后在join之后收集返回值。

在热搜词里还有“java 多线程执行sql语句时，程序等sql执行完毕后，再执行下一条”，这种场景用CompletableFuture非常合适。代码骨架是这样：

java复制// 假设有一批SQL要执行，不能用默认的commonPool，因为SQL是阻塞操作
ExecutorService sqlPool = Executors.newFixedThreadPool(8);
List<CompletableFuture<Void>> tasks = new ArrayList<>();
for (String sql : sqlList) {
    CompletableFuture<Void> future = CompletableFuture.runAsync(() -> executeSql(sql), sqlPool);
    tasks.add(future);
}
CompletableFuture.allOf(tasks.toArray(new CompletableFuture[0])).join();

这里必须记住一个坑：CompletableFuture如果没指定线程池，默认使用ForkJoinPool.commonPool()，而公共线程池的大小是CPU核数减1。SQL这种阻塞操作如果丢到commonPool里去跑，很容易把公共线程池里的线程全部占满，拖垮其他不相关的异步任务。所以在生产环境里，凡是涉及阻塞操作的异步任务，都建议自己创建专用线程池传入。

关于“多线程打印1~100”本身，用CompletableFuture去硬凑顺序是得不偿失的。真要强行按顺序，可以先提交100个任务，每个任务的逻辑是“循环等待直到轮到自己”，但那个复杂度已经背离了CompletableFuture的设计初衷。CompletableFuture的强项是异步编排，而不是做线程间的交替协作。

4. 横向对比——C++、Python、Linux C是怎么写的

4.1 C++11：std::thread + mutex + condition_variable

跨出Java看C++，思路其实是一样的。C++11标准库已经内置了线程库，写起来不算麻烦：

cpp复制#include <iostream>
#include <thread>
#include <mutex>
#include <condition_variable>

std::mutex mtx;
std::condition_variable cv;
int current = 1;
const int LIMIT = 100;
const int THREAD_COUNT = 3;

void printNum(int id) {
    while (true) {
        std::unique_lock<std::mutex> lock(mtx);
        cv.wait(lock, [id]() {
            return current > LIMIT || current % THREAD_COUNT == id;
        });
        if (current > LIMIT) {
            cv.notify_all();
            break;
        }
        std::cout << "线程" << id << "打印: " << current << std::endl;
        ++current;
        cv.notify_all();
    }
}

int main() {
    std::thread threads[THREAD_COUNT];
    for (int i = 0; i < THREAD_COUNT; ++i) {
        threads[i] = std::thread(printNum, i);
    }
    for (auto &t : threads) {
        t.join();
    }
    return 0;
}

C++的condition_variable::wait有个方便的用法：第二个参数传一个lambda作为条件判断，内部会自己处理“条件不满足就继续等待”的逻辑，不需要你写while循环。这个其实是包装了“防止虚假唤醒”的机制，比Java的裸wait更友好。

编译时记得加线程库，很多新手在Linux下编译报错就是漏了这一步：

bash复制g++ -std=c++11 -pthread print.cpp -o print

C++中传递参数给线程函数时要小心实参的引用传递。如果想让线程修改某个外部变量，需要显式使用std::ref包一层，否则线程拿到的是拷贝，修改不生效。

4.2 Python：GIL下的threading + Lock

Python的多线程有个绕不开的话题：GIL（全局解释器锁）。它使得同一时刻只有一个线程能执行Python字节码，所以很多人说Python多线程是“假的”。但GIL只解决了解释器层面的互斥，并不解决业务数据的原子性问题，你的代码该加锁还是要加锁。

python复制import threading

lock = threading.Lock()
current = 1
LIMIT = 100
THREAD_COUNT = 3

def print_num(thread_id):
    global current
    while True:
        with lock:
            if current > LIMIT:
                break
            if current % THREAD_COUNT == thread_id:
                print(f"线程{thread_id}打印: {current}")
                current += 1

threads = [threading.Thread(target=print_num, args=(i,)) for i in range(THREAD_COUNT)]
for t in threads:
    t.start()
for t in threads:
    t.join()

Python这个版本用with lock相当于Java的synchronized块，进入自动加锁，退出自动释放，非常简洁。要注意的是，print函数本身是线程安全的，但我们把“判断条件 + 打印 + 自增”整体放在锁里面，是为了保证这三个动作的原子性，防止两个线程同时通过判断。如果不加锁，在GIL下偶尔也能跑对，但那是运气，不是正确性。

Python多线程真正的适用场景是IO密集型的任务，比如爬虫、文件读写、数据库查询。这些任务会频繁让出GIL等待IO结果，线程切换反而能提升整体吞吐。如果是CPU密集型的计算任务，Python多线程帮不上忙，这时候应该考虑多进程（multiprocessing）或者用asyncio方案。

4.3 Linux C：pthread_mutex_t与pthread_cond_t的经典搭配

Linux C风格的多线程编程没有C++标准库那种语法糖，但它的API设计影响了很多语言的线程库设计。看一遍C的写法，你对Java和C++里面的底层机制会理解得更深。

c复制#include <stdio.h>
#include <pthread.h>

#define LIMIT 100
#define THREAD_COUNT 3

pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
int current = 1;

void* print_num(void* arg) {
    int id = *(int*)arg;
    while (1) {
        pthread_mutex_lock(&mtx);
        while (current <= LIMIT && current % THREAD_COUNT != id) {
            pthread_cond_wait(&cond, &mtx);
        }
        if (current > LIMIT) {
            pthread_cond_broadcast(&cond);
            pthread_mutex_unlock(&mtx);
            break;
        }
        printf("线程%d打印: %d\n", id, current);
        current++;
        pthread_cond_broadcast(&cond);
        pthread_mutex_unlock(&mtx);
    }
    return NULL;
}

int main() {
    pthread_t threads[THREAD_COUNT];
    int ids[THREAD_COUNT];
    for (int i = 0; i < THREAD_COUNT; i++) {
        ids[i] = i;
        pthread_create(&threads[i], NULL, print_num, &ids[i]);
    }
    for (int i = 0; i < THREAD_COUNT; i++) {
        pthread_join(threads[i], NULL);
    }
    return 0;
}

C的写法里，pthread_cond_wait传入的参数是mutex，这是它的一个关键设计：线程进入等待前会原子地释放mutex，被唤醒后再重新持有mutex。如果不理解这个“释放-等待-唤醒-重持”的过程，你去看其它语言的条件变量源码会一头雾水。

这里有个典型的坑：pthread_create传入整数参数时，如果直接传入循环变量i的地址，所有线程可能拿到同一个值。因为i在循环结束后的值是不确定的，线程真正读取的时候可能已经变成了3。所以要复制一份id到数组里，每个线程用自己独立的id。这种“变量地址被共享”的问题，在Java里反而不容易出现，因为Java的lambda表达式捕获变量时会复制值。

编译命令也要记得加上-pthread：

bash复制gcc print.c -o print -pthread

5. 从打印100个数到真实并发任务——线程池、任务编排与性能边界

5.1 for循环里提交任务，怎么等全部执行完

回到热搜词里的真实场景：“java for循环内的多线程”、“等sql执行完毕后再执行下一条”。这种需求在生产代码里太常见了，比如批量更新一批数据、批量调用外部接口、批量处理文件。核心问题就两个：用什么样的线程池，以及如何等待所有任务完成。

我总结三种等待方式，你可以根据场景选：

java复制// 方式一：CountDownLatch
CountDownLatch latch = new CountDownLatch(taskCount);
for (Task task : tasks) {
    pool.execute(() -> {
        try {
            doTask(task);
        } finally {
            latch.countDown();
        }
    });
}
latch.await(); // 阻塞直到计数器归零

java复制// 方式二：Future + get
List<Future<?>> futures = new ArrayList<>();
for (Task task : tasks) {
    futures.add(pool.submit(() -> doTask(task)));
}
for (Future<?> future : futures) {
    future.get(); // 逐个获取结果，没有则阻塞
}

java复制// 方式三：CompletableFuture.allOf
List<CompletableFuture<Void>> futures = new ArrayList<>();
for (Task task : tasks) {
    futures.add(CompletableFuture.runAsync(() -> doTask(task), pool));
}
CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])).join();

三种方式各有侧重。CountDownLatch代码直观，适合只关心“都跑完了没”的场景，但拿不到每个任务的结果，如果业务需要结果，还得自己封装容器。Future.get适合需要收集每个任务返回值的场景，但代码稍显啰嗦。CompletableFuture是最现代的写法，链式调用清晰，还支持并行聚合、异常处理，是优先推荐的选择。

中间有个细节值得注意：CountDownLatch的countDown一定要放在finally里。一旦任务执行抛异常而你没有finally，计数器永远无法归零，主线程就会一直阻塞在那里。这是线上非常典型的“程序假死”事故原因。

5.2 线程池参数：线程数、队列、拒绝策略怎么选

不管用什么并发工具，线程池参数配置是绕不开的环节。很多新手默认Executors.newFixedThreadPool(10)一把梭，实际到线上就被打脸。

先看线程数的估算。CPU密集型任务，线程数一般设为CPU核数加1就够了。为什么加1？因为总有一个线程可能因为缺页中断或者别的调度原因短暂等待，多一个线程可以顶上去，保证CPU尽量不休眠。IO密集型任务，线程数可以设到CPU核数的两倍甚至更高，因为IO等待期间线程会让出CPU，需要更多线程来填充等待期。常见公式是：IO密集型线程数 = CPU核数 * (1 + 平均等待时间 / 平均计算时间)，这个比例只能靠压测慢慢调，没有统一标准。

再看队列。Executors.newFixedThreadPool默认用的是无界LinkedBlockingQueue，任务没有上限，一旦任务提交速度超过消费速度，内存就会被不断堆积，最后OOM。生产环境建议使用有界队列，比如ArrayBlockingQueue(capacity)或者ThreadPoolExecutor自己定制的队列。配合有界队列，再设置一个合理的拒绝策略。

拒绝策略也是经常被忽略的点。AbortPolicy直接抛异常，是最安全也最容易引发故障的；CallerRunsPolicy让提交任务的线程自己执行，是一种“慢下来”的反压机制，我比较推荐在高并发写入场景使用；DiscardPolicy和DiscardOldestPolicy会静默丢弃任务，除非你能容忍丢数据，否则不要用。

给你一个生产环境更稳的写法参考：

java复制ThreadPoolExecutor pool = new ThreadPoolExecutor(
    8,                 // 核心线程数
    16,                // 最大线程数
    60L, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(1000),  // 有界队列
    new ThreadPoolExecutor.CallerRunsPolicy()
);

这样线程数达到上限、队列也满了之后，新任务由提交方线程执行，相当于把压力反推回去，不会导致系统瞬间崩溃。

5.3 打印这个场景对性能的启发：同步开销与上下文切换

我们回到打印题本身，做一个简单的性能思考：你这套代码跑100万次，瓶颈在哪里？

第一个瓶颈是锁竞争。每次打印都要加锁、释放锁，所有线程挤在同一个临界区上排队，吞吐量其实很低。你用synchronized和ReentrantLock跑一个基准测试，会发现二者的差距可能在10%到30%之间，但在这种“锁粒度极小”的场景下，这种差距会被放大。

第二个瓶颈是上下文切换。线程过多，操作系统就要频繁切换执行流，每次切换都有成本。假设你在一个有8核的机器上开100个线程去打印，大部分线程其实都在等待锁，调度器还得在它们之间来回切换，纯属增加负担。

所以这道题给我们的真实经验是：多线程能提速的前提是任务之间没有强依赖，可以真正并行；一旦任务必须在顺序上严格依赖，多线程带来的更多是同步开销。生产环境里，如果多个任务最终必须合并结果，优先考虑“分片并行 + 汇总串行”的设计模式，而不是强行在共享变量上做文章。

6. 面试追问与线上问题排查——这道题的高频考点和避坑实录

6.1 面试官最爱追问的几个点

我面试别人的时候，如果候选人能把打印题顺利写出来，我通常会顺着问几个问题，每个问题都能刷掉一批人。

第一个问题：你这几个线程的个数是怎么定的，3个线程打印100个数，每个线程大概打印多少个？这个问题的陷阱在于，不是简单地100除以3。由于取模分配，三个线程打印的数量可能不是均匀的，最后一段余数会多出来。候选人如果没想过这个问题，会卡住。

第二个问题：能不能用volatile解决？回答这个问题要区分场景。如果题目不要求顺序，只要求不重不漏，volatile不能替代锁，因为它保证不了原子性；如果只是靠volatile保证可见性，i++还是可能重复。但如果结合AtomicInteger，它内部用的是CAS，可以做到无锁原子自增，那是另外一条技术路线。

第三个问题：怎么优雅地停掉线程？很多人会说用stop或者destroy，这是错误答案。Java早就废弃了Thread.stop，正确做法是通过标志位协作中断。更规范的用法是使用interrupt机制，在循环里检查Thread.currentThread().isInterrupted()，捕获InterruptedException后恢复中断状态。

第四个问题：如果把这100个打印任务丢给线程池，怎么保证结果不丢？这就回到了第5节的内容：要用Future收集结果，用CountDownLatch等待结束，用异常处理兜底。回答这个问题时，能把CompletableFuture的allOf和自定义线程池参数说清楚，会让面试官眼前一亮。

第五个问题：三个线程怎么改成两个线程，让一个打印奇数一个打印偶数？本质上把条件从“余数等于线程id”改成“数字是奇数还是偶数”，逻辑一样。但要注意边界条件，比如线程全部退出时如何互相通知，跟前面的问题一样。

6.2 常见问题速查表

我在实际写代码和带新人的过程中，总结了下面这张速查表，基本覆盖了这道题所有常见故障。

第三行“打印完100但JVM不退出”是把题目改成Java之后最容易遇到的现象。原因是主线程本身可能正常结束了，但子线程还在wait状态。Java的JVM会在所有非守护线程退出后才退出，所以你会在控制台上看到100已经打印完了，但程序却一直挂着。解决方式就是前面代码里写的，break之前通知其他线程“你别等了”。

6.3 排查死锁和超印漏印的几条经验

线上排查并发问题，我一般按三条路线走。

第一条路线是看线程状态。直接用jstack导线程快照，或者用jconsole可视化查看。如果一个线程长时间处于WAITING或BLOCKED状态，基本可以断定它在等一把锁。如果看到两个线程各自持有一把锁又在等对方释放，那就是典型的死锁。JVM的jstack会在最后给出Found one Java-level deadlock提示，直接定位。

第二条路线是加日志输出，但别乱加。不要在锁内部打日志，否则日志本身会成为新的性能瓶颈。正确的做法是记录关键节点的线程ID和值，用字符串拼接而不是多次println，确保日志内容在临界区内是完整的。日志也可以用来验证“每个线程打印了哪些数”，排查出超印漏印。

第三条路线是用工具模拟复现。我常写一个小脚本，把线程数设大一点（比如10个或20个），循环次数设多一点（比如1万或10万），然后统计输出结果是否完整。如果是超印漏印，错误会在高循环次数下快速暴露。模拟复现之后再收缩到一个能稳定触发问题的最小用例，方便定位。

排查过程中有一个容易被忽略的地方：打印结果在控制台可能正常，但重定向到文件后就乱序了。这是因为System.out本身有内部缓冲，多个线程的打印内容可能被打散。如果你需要严格记录顺序，应该把输出内容拼成一条完整的字符串，再一次性写入文件。

最后的实操建议

这道题我看着简单，但真让我手写一遍，还是会仔细过一遍“谁唤醒谁、谁来退出、异常怎么处理”三件事。我自己带新人时，会要求他们把这道题至少写三遍：第一遍用synchronized，第二遍用ReentrantLock，第三遍用Semaphore；写完之后再试着自己改成打印“ABC”的变体。能完整走过这三遍的人，并发编程的基本功基本就过关了。

你也不用急着看更高深的并发源码。把每个方案跑起来，打断点看线程卡在哪一行，多试几次错，对概念的感知远比背八股深刻。等你哪天真在线上遇到“任务卡住不走了”，你回过头想今天这道打印题，会发现都是同一套东西。