多线程打印1~100：从竞争到协作的并发编程实战-代码聚汇网

多线程打印1~100：从竞争到协作的并发编程实战

不吃章鱼烧·2026-09-06·阅读 22 GEO检测（免费）

多线程并发编程线程同步

|难度：普通|阅读约 35 分钟

1. 为什么一个“打印数字”的小程序，成了多线程入门绕不开的坎

别小看“多线程打印1~100”这个需求，它几乎是所有后端开发、客户端开发、嵌入式开发面试题库里出场率最高的入门题之一。表面上看，无非是让几个线程把100个数字按顺序输出到控制台，好像写个for循环就够了。但真把这段代码放到多线程环境里跑一遍，你会发现各种奇奇怪怪的问题：数字重复了、顺序乱跳、甚至程序直接卡死。

这个题目真正考察的，不是你会不会写循环，而是你对线程调度、临界区、同步机制、内存可见性这几块基础功底的掌握程度。它把并发编程里最核心的复杂度，浓缩到了一个极其简单的场景里。打个比方，这就好比教人做饭从“煎鸡蛋”开始——食材简单，但火候、油温、翻面的时机全都得对，错了蛋就糊了。

我见过不少工作了三五年的开发，谈起分布式、消息队列头头是道，但你让他现场写一个两个线程交替打印奇偶数的Demo，他反而会卡壳。原因很简单：他平时写的业务代码，CRUD居多，并发场景早就被框架封装好了，真正在底层处理线程同步的机会并不多。所以这个题目在面试里的价值极高，它像一把卡尺，能快速量出一个人对并发基础的理解深度。

这篇文章会用Java为主语言，辅以C++、Python、Qt和Linux下的一些对照实现，把这道题拆开揉碎。不管你是刚接触多线程的初学者，还是想查漏补缺的经验开发者，都能从中拿到一些实际可用的思路和避坑经验。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 核心概念拆解：先搞清楚多线程到底在“并发”些什么

2.1 三个悲催线程和一个共享计数器的“打架”过程

先想象一个最直观的场景。你现在有3个线程，目标是按顺序打印1到100。最朴素的思路是什么？定义一个共享变量count = 1，三个线程同时去读这个变量，读到一个数就打印一个，然后count++，直到count > 100为止。

看起来天衣无缝对吧？但实际跑起来，你会发现同一轮里三个线程可能打印出相同的数字，或者数字之间空隙非常大。原因在于，count++这个操作在CPU层面不是一条指令，而是三条：

把count从内存读到寄存器
在寄存器里加1
把新值写回内存

如果线程A刚把count=5读到寄存器，还没来得及写回6，线程B也把count=5读走了，那打印出来的就是两个5。这就是经典的“读-改-写”竞态条件。更麻烦的是，在Java的内存模型里，每个线程还有自己的工作内存（CPU缓存），一个线程修改了count，另一个线程不一定能立刻看到，这就是可见性问题。

这也是为什么这个题目如此经典。它让你亲手复现一遍竞态条件和可见性问题，比任何理论文档都直观。你不需要去背“原子性、可见性、有序性”的概念，只需要看着控制台输出的一堆乱序数字，就能深刻理解这些抽象名词背后的真实含义。

2.2 线程创建到底有几种姿势，区别在哪

在Java里创建线程主流有三种方式：

继承Thread类。直接extends Thread，重写run()方法，然后start()。好处是代码直观，适合超简单的场景。坏处是Java单继承，你继承了Thread就没法继承别的类了，而且逻辑和线程本身耦合在一起，不利于后期维护。

实现Runnable接口。这是我个人最推荐的方式。把任务逻辑单独抽出来，线程只是个执行载体。需要复用同样的任务逻辑时，可以丢给多个线程跑，任务和线程的生命周期分离，代码更干净。

使用Callable和FutureTask。Runnable的run()方法没有返回值，也没法抛受检异常。如果你的任务需要返回结果，比如计算完100个数的总和再返回，就得用Callable。配合FutureTask或者线程池，能拿到异步执行的结果。

下面这段代码展示了Runnable方式的基本写法：

java复制public class PrintTask implements Runnable {
    private int count = 1;
    private final Object lock = new Object();

    @Override
    public void run() {
        while (true) {
            synchronized (lock) {
                if (count > 100) {
                    break;
                }
                System.out.println(Thread.currentThread().getName() + ": " + count);
                count++;
            }
        }
    }
}

这段代码用synchronized锁住了lock对象，保证同一时刻只有一个线程能进入临界区操作count。count是一个实例变量，多个线程共享同一个PrintTask实例时，它们操作的就是同一个计数器。

3. 从“能用”到“好用”：三种实现方案及选型逻辑

3.1 方案一：synchronized关键字，最朴素也最可靠

synchronized是Java内置的同步机制，它解决的是互斥访问的问题。你可以锁一个方法，也可以锁一个代码块。锁的本质是：当一个线程持有锁时，其他试图进入同一把锁保护区域的线程必须阻塞等待。

放在这个题目里，保护的区域就是“读取count、判断是否大于100、打印、自增”这一整段逻辑。为什么不能只锁count++那一行？因为判断count > 100和打印也必须放在同一把锁内，否则会出现两个线程同时通过检查，然后一起打印同一个数的情况。

synchronized的优点是：使用简单、不会忘记释放锁（JVM自动处理）、可重入（同一个线程可以重复进入同一把锁）。缺点是：它不支持超时中断，如果持锁线程卡死，其他线程会一直等下去。而且synchronized在竞争激烈时性能表现一般，不过Java 6之后引入了偏向锁、轻量级锁的优化，大部分场景下已经够用。

一个常见的疑问是：synchronized(this)和synchronized(PrintTask.class)有没有区别？有。区别在于锁的作用域。如果多个线程共享同一个PrintTask实例，那锁住this就够了。但如果多个线程各自持有不同的PrintTask实例，却要操作同一个静态计数器，那就必须锁类对象。写代码前先想清楚你的锁到底在保护谁。

3.2 方案二：ReentrantLock，更灵活的“手动锁”

ReentrantLock是java.util.concurrent.locks包下的显式锁。它和synchronized最大的区别是：锁的获取和释放需要手动控制，也因此提供了更多高级功能。

先看基础用法：

java复制public class PrintTaskWithLock {
    private int count = 1;
    private final Lock lock = new ReentrantLock();

    public void print() {
        while (true) {
            lock.lock();
            try {
                if (count > 100) {
                    return;
                }
                System.out.println(Thread.currentThread().getName() + ": " + count);
                count++;
            } finally {
                lock.unlock();
            }
        }
    }
}

记住一个铁律：lock()之后必须在finally里unlock()。如果你忘了释放锁，其他线程会永久阻塞。这不是危言耸听，我见过线上事故就是因为某个异常路径上没走到unlock()，导致线程池里的工作线程全部卡死。

ReentrantLock真正强大的地方在于它支持tryLock(timeout)。这意味着你可以设置一个等待时间，万一锁被别的线程持有太久，当前线程可以放弃等待而不是无限阻塞。这在处理复杂业务时非常有用。另外它还可以创建公平锁：new ReentrantLock(true)。公平锁严格按照线程申请锁的顺序来排队，避免线程饥饿，但性能上会比非公平锁略差一些。

回到这个题目，如果只是顺序打印1到100，synchronized和ReentrantLock在结果上没有区别。选择哪个更多取决于你后续的需求：要不要超时控制？要不要公平策略？要不要支持多个条件变量？

3.3 方案三：AtomicInteger加自旋，无锁并发的高级玩法

前面说count++不是一个原子操作，那如果直接把count换成AtomicInteger呢？AtomicInteger内部的自增操作incrementAndGet()是基于CAS（Compare-And-Swap）实现的，它保证了读-改-写这个过程的原子性。

但这里有个坑：即使自增变成了原子操作，你的“判断+打印”逻辑仍然不是一个原子块。你可以在代码里看到这个经典的反面教材：

java复制while (true) {
    int current = atomicCount.get();
    if (current > 100) break;
    System.out.println(Thread.currentThread().getName() + ": " + current);
    atomicCount.incrementAndGet();
}

这段代码看起来好像是对的，但实际跑起来会出现两个线程打印同一个数字。为什么？因为线程A读取到current=5，还没来得及打印，线程B也读取到了current=5，两个线程都打印了5。

解决办法是让整个“读取-判断-打印-自增”过程变成一个原子操作。可以用Synchronized包住这段逻辑，但那就等于绕回了方案一。也可以用AtomicInteger的updateAndGet配合函数式接口来实现更复杂的CAS重试，但在这个场景下实现起来比较绕，复杂度反而上去了。

所以AtomicInteger在本题中更适合的场景是：你只需要保证count的自增是原子的，而不关心打印顺序是否严格一致。比如三个线程并发统计从1加到100的总和，每个线程拿到的数可以被重复处理，只要最终自增不丢数就行。如果你要求严格按顺序输出，还是得靠锁或信号量。

4. 用多线程打印1到100，还需要经历的几个“进阶关卡”

4.1 三个线程轮流打印怎么设计：Condition的精妙用法

如果题目的要求升级为“三个线程分别打印1到100中的一部分，并且按顺序轮流输出”，比如线程A打1，线程B打2，线程C打3，线程A再打4，这样循环下去，该怎么办？

这时候只用一把锁已经不够了，你还需要“按条件唤醒指定线程”。ReentrantLock提供了newCondition()方法，每个Condition实例维护了一个独立的等待队列。

设计思路如下：

启动三个线程，每个线程有自己的编号id（0、1、2）
共享一个状态变量state，初始值为0
线程执行时判断state % 3 == id，如果是就打印并state++，然后唤醒下一个线程；否则就进入等待状态

Java代码可以这样写：

java复制public class AlternatePrint {
    private int state = 1;  // 当前应该打印的数字
    private final Lock lock = new ReentrantLock();
    private final Condition[] conditions = new Condition[3];

    public AlternatePrint() {
        for (int i = 0; i < 3; i++) {
            conditions[i] = lock.newCondition();
        }
    }

    public void print(int threadId) {
        for (int i = 0; i < 34; i++) {
            lock.lock();
            try {
                // 判断是不是轮到自己了
                // 这里用 numOfThread 取模来决定当前轮到哪个线程
                while (state % 3 != threadId) {
                    conditions[threadId].await();
                }
                if (state <= 100) {
                    System.out.println("线程" + threadId + ": " + state);
                }
                state++;
                // 唤醒下一个线程
                conditions[(threadId + 1) % 3].signal();
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            } finally {
                lock.unlock();
            }
        }
    }
}

这里最需要注意的是await()方法的使用场景。await()必须在持有锁的情况下调用，它会释放当前线程持有的锁，并让线程进入等待状态。当被signal()唤醒后，线程会重新尝试获取锁，然后从await()返回，继续执行后面的代码。

用while而不是if来包裹await()，这个细节很关键。如果只判断一次，线程被唤醒后可能发现条件依然不满足（比如被异常唤醒），就会执行不该执行的逻辑。while循环能确保线程在被唤醒后重新检查条件，这就是所谓的“循环等待”模式。

4.2 按顺序打印1到100，而不只是“不重复打印”

另一个常见变体是：要求多个线程按严格的数字顺序输出，即1、2、3...直到100，每打印一个数字只允许一个线程执行。这看起来和基础版本一样，但真正的难点在于如何让多个线程“排队接力”。

如果你直接让三个线程都进入一个synchronized块，然后依次打印，这也能实现顺序输出，但问题在于：三个线程同时竞争一把锁，谁能拿到锁完全是随机的。即使A刚打印完1并释放锁，下一个拿到锁的可能是B也可能是C。如果B拿到锁，它会打印2吗？会，只要逻辑是“拿到锁就打印当前count值并自增”。因为此时count已经是2了，不管哪个线程拿到锁，打印的值都是正确的。

所以顺序打印的难点其实不只是“锁”，而是如何控制线程的启动顺序和竞争行为。最直接的办法是用Thread.join()让线程按顺序一个接一个执行，但这本质上退化成了单线程，失去了多线程的意义。更合理的做法是让每个线程在“不该自己干活的时候主动让出CPU”。

Java里可以用Thread.yield()做简单的礼让，但它只是给调度器一个提示，不保证任何行为。生产环境中更可靠的方式是使用信号量（Semaphore）。你可以为每个线程分配一个独立的信号量，初始只给第一个线程一个许可，其他线程都是0。第一个线程打印完1之后，释放第二个线程的信号量，如此接力：

java复制public class SemaphorePrint {
    private Semaphore[] semaphores;
    private int count = 1;

    public SemaphorePrint(int threadCount) {
        semaphores = new Semaphore[threadCount];
        for (int i = 0; i < threadCount; i++) {
            semaphores[i] = new Semaphore(i == 0 ? 1 : 0);
        }
    }

    public void print(int threadId) {
        while (true) {
            try {
                semaphores[threadId].acquire();
                if (count > 100) break;
                System.out.println("线程" + threadId + ": " + count);
                count++;
                semaphores[(threadId + 1) % semaphores.length].release();
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }
    }
}

这个方案的优点是流程清晰、配合关系明确，非常适合多线程协作的场景。你只需要把信号量想象成“接力棒”，谁手里有棒谁干活，干完就传给下一个人。

4.3 CompletableFuture与线程池场景下的等待与结果聚合

如果你项目中已经用了线程池和CompletableFuture，这个题目还能玩出另一个维度：用异步任务来打印数字，并等待所有任务执行完毕。

比如把1到100分成多个批次，每个批次交给一个异步任务打印。关键的问题在于CompletableFuture的异步任务默认在ForkJoinPool.commonPool()中执行，如果你需要控制并发度，最好自定义线程池。

java复制ExecutorService executor = Executors.newFixedThreadPool(5);
List<CompletableFuture<Void>> futures = new ArrayList<>();

for (int i = 1; i <= 100; i++) {
    int value = i;
    CompletableFuture<Void> future = CompletableFuture.runAsync(() -> {
        System.out.println(Thread.currentThread().getName() + ": " + value);
    }, executor);
    futures.add(future);
}

CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])).join();
executor.shutdown();

这段逻辑本身并不复杂，但有个隐蔽的坑：CompletableFuture.runAsync()的任务提交顺序和实际执行顺序不一定一致，因为线程池里的线程是并行消费任务的。也就是说，你用这种方式无法保证按1到100的顺序输出，只能保证所有打印任务都执行完。

如果你需要“等一个任务的结果出来后再做下一步”，可以用thenApply()、thenCompose()或者thenAccept()。举个例子：

java复制CompletableFuture.supplyAsync(() -> 1, executor)
    .thenApply(x -> x + 1)
    .thenApply(x -> x * 10)
    .thenAccept(System.out::println);

这段代码就是典型的“等待任务结果再执行下一步”的模式。thenApply接收上一个阶段的结果并转换，thenAccept消费最终结果。这种方式非常适合流水线式的异步编排。

5. 多语言横评：同样的题目，C++、Python、Qt、Linux各自的实现

5.1 C++里用thread和mutex重写一遍

C++11开始提供了标准的多线程库std::thread、std::mutex、std::condition_variable，语法上比Java更贴近底层。同样的打印任务，C++写出来大概是这个样子：

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

std::mutex mtx;
int count = 1;

void print(int threadId) {
    while (true) {
        std::lock_guard<std::mutex> lock(mtx);
        if (count > 100) break;
        std::cout << "thread " << threadId << ": " << count << std::endl;
        count++;
    }
}

int main() {
    std::thread t1(print, 0);
    std::thread t2(print, 1);
    std::thread t3(print, 2);

    t1.join();
    t2.join();
    t3.join();
    return 0;
}

这里用std::lock_guard可以自动管理锁的释放，作用域结束就解锁，比手动lock()/unlock()安全。std::cout本身是线程安全的，但多条<<操作组合在一起不是原子的，所以整个打印过程还是要放进锁里。否则你可能看到某一行输出被另一个线程的输出插入打断。

C++的另一个特色是std::this_thread::yield()和std::this_thread::sleep_for(std::chrono::milliseconds(...))。在多线程调试时，我经常在关键位置加一小段sleep_for来放大竞态问题，让肉眼能看清线程调度的交错过程，调试完再删掉。

5.2 Python的GIL让你踩的第一个坑：多线程可能比单线程还慢

Python的多线程有一个绕不开的话题：GIL（全局解释器锁）。因为GIL的存在，同一时刻只有一个线程能执行Python字节码。所以对于CPU密集型的任务，Python多线程不仅不能加速，反而会因为线程切换带来额外开销。

对于“打印1到100”这种包含大量I/O操作的任务，GIL的影响会体现在哪里呢？答案是：输出操作本身会释放GIL，但线程调度仍然受到GIL的牵制。一个简单的事实是，Python多线程打印1到100的正确实现也要加锁，否则依然会出现乱序和重复。

python复制import threading

lock = threading.Lock()
count = 1

def print_num(thread_id):
    global count
    while True:
        with lock:
            if count > 100:
                break
            print(f"thread{thread_id}: {count}")
            count += 1

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

with lock是threading.Lock的上下文管理器写法，等价于lock.acquire()和lock.release()，代码更简洁。Python另一个好用的是threading.Event和threading.Condition，在多线程协作场景比单纯用锁更灵活。

Python生态里还有一个concurrent.futures模块，提供了类似Java CompletableFuture的ThreadPoolExecutor和as_completed()，适合批量提交任务并等待结果。如果你的Python程序里有大量I/O等待，用ThreadPoolExecutor能显著提高吞吐量。

5.3 Qt里多线程UI更新的那点事

Qt的多线程模型和纯Java、纯C++有一个显著不同：它强制要求UI操作必须在主线程进行。子线程不能直接调用QLabel::setText()或者QTextEdit::append()，否则轻则界面无响应，重则直接崩溃。

Qt官方推荐的做法是使用信号槽机制。子线程负责计算，然后通过信号把结果发射出去，主线程的槽函数接收到信号后再去更新UI。这种设计天然规避了多线程直接操作UI的脏问题。

cpp复制// Worker 类
class Worker : public QObject {
    Q_OBJECT
public slots:
    void doWork() {
        for (int i = 1; i <= 100; i++) {
            emit numberReady(i);
        }
    }
signals:
    void numberReady(int value);
};

// 主线程中连接
Worker *worker = new Worker;
QThread *thread = new QThread;
worker->moveToThread(thread);

connect(thread, &QThread::started, worker, &Worker::doWork);
connect(worker, &Worker::numberReady, this, [this](int value) {
    ui->textEdit->append(QString::number(value));
});
connect(worker, &Worker::finished, thread, &QThread::quit);

这段代码里，moveToThread()把worker对象移到了新线程，信号槽的跨线程连接方式会自动变为队列连接（QueuedConnection），信号发射后不会立刻执行槽函数，而是进入接收者所在事件队列排队等待处理。这是Qt多线程编程里最容易出错也最重要的知识点。

5.4 Linux C++里pthread的原始用法

Linux平台下经典的POSIX线程库pthread，API设计非常原始但功能强大。pthread_create创建线程，pthread_mutex_lock加锁，pthread_cond_wait条件等待，每一步都需要自己管理。

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

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
int count = 1;

void *print_num(void *arg) {
    long thread_id = (long)arg;
    while (1) {
        pthread_mutex_lock(&mutex);
        if (count > 100) {
            pthread_mutex_unlock(&mutex);
            break;
        }
        printf("thread %ld: %d\n", thread_id, count);
        count++;
        pthread_mutex_unlock(&mutex);
    }
    return NULL;
}

int main() {
    pthread_t threads[3];
    for (long i = 0; i < 3; i++) {
        pthread_create(&threads[i], NULL, print_num, (void *)i);
    }
    for (int i = 0; i < 3; i++) {
        pthread_join(threads[i], NULL);
    }
    pthread_mutex_destroy(&mutex);
    return 0;
}

这段代码的优点是没有多余的黑盒，所有同步机制都摆在明面上。你很容易理解锁的粒度和作用范围。但风险也在这：手动管理锁容易忘解锁，条件变量用不好容易死锁，对内存序的理解不到位还会出现诡异的重排序问题。Linux下做多线程编程，valgrind --tool=helgrind和gdb是排查并发问题的两大法宝，前者能检测数据竞争和锁序问题，后者能查看线程栈和锁状态。

6. 多线程面试题里的“标准套路”与常见问题排查

6.1 面试官到底在问什么：隐藏考点全解析

面试官出“多线程打印1~100”这道题，通常不会只满足于你写出一段能跑的同步代码。他真正想通过追问确认的，大概有这么几个层面：

第一层是语法层面。你知不知道Java里创建线程的几种方式？synchronized和ReentrantLock的区别？volatile和synchronized的作用范围有何不同？这一层只要背过八股文就能过关。

第二层是设计层面。他可能会问：如果我用volatile修饰count能不能替代synchronized？答案是不能。volatile只能保证可见性和有序性，不能保证原子性。count++不是原子操作，即使count是volatile，两个线程同时自增还是会丢值。这个问题能筛掉一批只会背概念的人。

第三层是原理层面。线程什么时候从用户态切换到内核态？锁竞争失败时线程是阻塞还是自旋？公平锁和非公平锁分别适合什么场景？这些问题需要你对操作系统的线程调度和JVM的锁优化有实际的理解。

第四层是场景拓展。面试官常常会追加：如果有100个线程打印1到100呢？如果有线程卡在打印上怎么超时处理？如果打印过程中抛异常，其他线程怎么感知？每一个追问都在考察你面对真实并发问题的解决思路。

6.2 踩过的坑：死锁、线程饥饿、CPU空转

实操过这个题目的人，多半都见过以下几个问题：

死锁。死锁的经典场景是两个线程各自持有一把锁，又互相等待对方持有的那部分资源。在这个题目里，如果你用了多把锁且加锁顺序不一致，就可能出现死锁。比如线程A先锁lock1再锁lock2，线程B先锁lock2再锁lock1，那当A持有lock1等待lock2、B持有lock2等待lock1时，两个线程就永远等下去了。避免死锁的通用法则是：所有线程按同样的顺序加锁。

线程饥饿。如果用了非公平锁，某些线程可能一直抢不到锁，导致它长时间得不到执行。虽然在这个打印任务里每个线程只是打印几个数字，饥饿现象不明显，但在任务量大的场景中就很致命。解决方案是使用公平锁，或者使用信号量控制每个线程获取资源的上限。

CPU空转。如果你在获取不到锁时使用了空循环（俗称自旋），比如while(!lock.tryLock())，CPU会被白白占满。真正的生产级代码里，短时间的自旋可以避免线程切换的开销，但长时间自旋只会浪费资源。正确的做法是设置自旋次数上限，超过后挂起线程。

排查这些问题时，我常用的手段是：先给每个线程加名字，然后在关键位置打印当前时间戳和线程调用栈。Java可以用jstack导出线程快照，观察哪些线程处于WAITING状态、哪些持有锁。C++可以用gdb attach到进程，执行thread apply all bt查看所有线程的调用栈。

6.3 一次实战排查：为什么我的三个线程只打印了51个数就停了

有一回我复现这道题时，写了一个自认为天衣无缝的版本：三个线程共享一个PrintTask实例，count是实例变量，run()方法里用synchronized加锁。跑起来发现，控制台每次都只打印到51左右就停了。

排查过程是这样的：先用jstack看了线程状态，发现三个线程并没有阻塞，状态全是RUNNABLE，但CPU占用突然降到0。再仔细看代码，发现问题出在while(true)循环里——synchronized块内的count > 100判断是准确的，但当count达到某个值后，线程并没有主动退出，而是拿着锁不停地进入下一次循环。由于三个线程用的是同一个锁，它们会互相阻塞，但理论上不会停止。

真正的原因让我哭笑不得：控制台缓冲区满了。我把输出内容重定向到了文件，但文件所在的磁盘满了，写入操作阻塞了所有线程。这提醒了我一件事：排查并发问题时，不要只盯着锁和同步本身，I/O阻塞、资源限制、外部环境都可能成为瓶颈。

从那以后，我做多线程性能测试都会特地加上完整的资源监控：CPU、内存、磁盘I/O、文件句柄数。并发出问题，很多时候不是代码逻辑的问题，而是资源被耗尽。

7. 几个让代码更专业的优化方向

如果你已经能顺畅实现这个题目，不妨再往深处走一步。以下三个优化方向，是把这个Demo从“教科书级别”推向“工程级别”的关键。

7.1 用线程池取代裸线程

直接用new Thread()创建线程存在着资源管理的问题：每个线程都会占用独立的栈空间，创建和销毁线程本身也有性能开销。如果你的程序需要频繁执行异步任务，复用线程是更理性的选择。

java复制ExecutorService pool = Executors.newFixedThreadPool(3);
for (int i = 1; i <= 10; i++) {
    final int taskId = i;
    pool.execute(() -> {
        System.out.println(Thread.currentThread().getName() + " 执行任务 " + taskId);
    });
}
pool.shutdown();

但在使用线程池时要警惕任务队列堆积问题。newFixedThreadPool用的底层队列是LinkedBlockingQueue，默认容量是Integer.MAX_VALUE，任务无限堆积时可能导致内存溢出。生产环境建议使用ThreadPoolExecutor手动指定队列大小和拒绝策略。

7.2 使用CompletableFuture编排异步流水线

当打印1到100的任务变成一组需要按顺序依赖的步骤时，CompletableFuture的优势就体现出来了。它可以把任务串成链式调用，每一步等待上一步的结果，同时不阻塞主线程。

比如你想模拟“逐段打印，每打印10个数后等待所有线程完成一次集结”的场景：

java复制ExecutorService executor = Executors.newFixedThreadPool(3);
for (int start = 1; start <= 100; start += 10) {
    int from = start;
    int to = Math.min(start + 9, 100);
    CompletableFuture<Void> phase = CompletableFuture.runAsync(() -> {
        for (int i = from; i <= to; i++) {
            System.out.println(Thread.currentThread().getName() + ": " + i);
        }
    }, executor);
    phase.join();  // 等待本阶段完成再进入下一阶段
}
executor.shutdown();

这里phase.join()会让主线程等待当前阶段完成，起到了一个简易的“栅栏”作用。如果不想阻塞主线程，可以把后续操作放在thenRun()里，形成异步链条。

7.3 从“正确”到“高效”：减少锁的持有时间

锁竞争是影响多线程性能的主要因素。你写这段打印代码时，可以想想这个问题：锁保护的临界区是不是越小越好？

比如下面的写法，把打印操作放在锁外，只会锁住count的读取和自增：

java复制public void run() {
    while (true) {
        int current;
        synchronized (lock) {
            if (count > 100) break;
            current = count++;
        }
        System.out.println(Thread.currentThread().getName() + ": " + current);
    }
}

这样锁的持有时间被缩短到极致，但顺序无法保证：线程A刚取出count=5并自增到6，可能还没来得及打印5，线程B就取出6并打印了。所以顺序要求高的场景，该把打印放进锁里还是得放。这其实是一个取舍问题：你想要严格的输出顺序，就要接受更长的临界区；如果你的核心诉求只是不重复、不丢失，那缩小锁的范围能明显提升并发性能。

8. 跑起来之前，这些前置细节先做好

8.1 环境准备和代码模板

无论你用哪种语言，动手前先把环境配好。以Java为例，建议直接用JDK 11以上版本，因为所谓“现代Java”的很多语法糖（比如var关键字）在新版本里更好用。IDE用IDEA或者VSCode都行，关键是能快速调试线程状态。

建议先把下面这个最小模板跑通，再逐步加需求：

java复制public class ThreadPrintDemo {
    public static void main(String[] args) {
        Runnable task = new PrintTask();
        Thread t1 = new Thread(task, "线程A");
        Thread t2 = new Thread(task, "线程B");
        Thread t3 = new Thread(task, "线程C");
        t1.start();
        t2.start();
        t3.start();
    }
}

记住：start()才是真正启动线程的方法。如果你手滑调用了run()，那只是在当前线程里同步执行任务体，不会产生并发效果。这是最基础也是新手最容易犯的错。

8.2 如何验证程序的输出是否完全正确

光靠肉眼把100个数从头到尾盯一遍，太累了而且容易看漏。最可靠的办法是把输出重定向到文件，再用脚本统计：

bash复制# 运行程序并把输出写入文件
java ThreadPrintDemo > output.txt

# 统计是否正好100行
wc -l output.txt

# 检查每一行里的数字是否严格递增
awk -F': ' '{print $2}' output.txt | uniq | wc -l
awk -F': ' '{if ($2 != last + 1) print "error at line " NR; last = $2}' output.txt

如果输出的数字严格从1递增到100且没有缺失，那说明程序正确。如果有重复或跳跃，就把执行次数加大，比如打印1到10000，竞态条件更容易暴露。

9. 最后再分享一个我自己的小技巧

这个题目做得多了，我反而越来越喜欢用它来做系统诊断。比如评估一台新机器的并发性能，我就写一个多线程打印任务，调节线程数和输出内容总量，观察CPU使用率和线程切换频率。这比装一堆基准测试工具来得直接。

如果你是想把这题练到“闭着眼都能写”的程度，我建议你按这个顺序练习：先把synchronized版本写熟，再改成ReentrantLock，接着用Semaphore实现轮流打印，最后用CompletableFuture做异步编排。每换一种同步机制，你对多线程的理解就会深一层。等到有一天你能不看文档，直接在脑海里画出线程状态流转图，这道入门题才算真正吃透了。