多线程核心价值是提升CPU利用率和整体吞吐量，通过让等待I/O的线程释放CPU给其他任务执行；需用线程池复用线程，避免频繁创建销毁；共享变量须用volatile、synchronized或AtomicInteger等机制同步；线程协作优先选用BlockingQueue、CountDownLatch等高级并发工具。
多线程不是为了“炫技”，而是解决阻塞和资源闲置
Java 程序默认是单线程执行的，main 方法跑完就退出。一旦遇到 I/O（比如读文件、发 HTTP 请求）、等待数据库响应、或调用 Thread.sleep()，当前线程就会卡住，CPU 干等着——而现代 CPU 动辄 4 核、8 核，空转就是浪费。
多线程的核心价值就一条：让 CPU 在某个线程等待时，去跑别的任务。它不提升单个任务的速度，但能显著提升整体吞吐量和响应性。
- Web 服务器每来一个 HTTP 请求，都用新线程处理，否则第二个请求得等第一个彻底结束才能开始
- GUI 应用中，界面刷新（AWT/Swing）必须在主线程，耗时计算（如解析大 JSON）若放进去，界面直接冻结；扔进新线程，UI 依然可点可拖
- 定时任务（如每 5 秒查一次库存）不能阻塞主流程，得靠
ScheduledExecutorService启动独立线程执行
并发 ≠ 随便 new Thread()，线程创建和销毁代价很高
频繁 new Thread() 会快速耗尽系统线程资源（Linux 默认每个进程约 1024 线程上限），且每次创建/销毁涉及内核态切换，开销远大于普通对象。
正确做法是复用线程——用线程池。JDK 自带的 Executors 工具类提供几种常见配置：
立即学习“Java免费学习笔记（深入）”；
-
Executors.newFixedThreadPool(4)：固定 4 个线程，适合 CPU 密集型任务（如图像压缩） -
Executors.newCachedThreadPool()：按需创建、60 秒空闲自动回收，适合大量短生命周期任务（如瞬时 Web 请求） -
Executors.newSingleThreadExecutor()：保证任务串行执行，避免竞态，适合写日志、更新共享计数器等场景
注意：newCachedThreadPool 在高并发突发下可能创建过多线程导致 OOM，生产环境更推荐用 ThreadPoolExecutor 显式配置核心线程数、队列容量和拒绝策略。
共享变量不加同步，结果大概率出错
多个线程同时读写同一个变量（如 int count = 0;），不加控制会出现“写丢失”：两个线程都读到 0，各自 +1 再写回，最终还是 1，而不是预期的 2。
这不是偶发 bug，是内存模型决定的必然现象。Java 的 volatile、synchronized、java.util.concurrent.atomic 包都是为解决这个问题：
-
volatile int count：保证可见性（一个线程改了，其他线程立刻看到），但不保证原子性（count++是读-改-写三步，仍可能冲突） -
synchronized(this) { count++; }：锁住临界区，确保同一时间只有一个线程执行，安全但有性能损耗 -
AtomicInteger count = new AtomicInteger(0); count.incrementAndGet();：底层用 CPU 的 CAS 指令实现无锁原子操作，高性能且线程安全
别迷信 synchronized —— 简单计数用 AtomicInteger，复杂逻辑才考虑锁；也别滥用 volatile，它不能替代锁。
线程间协作靠 wait/notify 或更高级的工具类
单纯“各干各的”不够，实际场景常需协调：比如生产者往队列塞数据，消费者从队列取数据，队列空时消费者该停，队列满时生产者该等。
原始 wait()/notify() 很容易写错：
- 必须在
synchronized块里调用，否则抛IllegalMonitorStateException -
notify()只唤醒一个线程，但无法指定唤醒谁；用notifyAll()更稳妥 - 必须用 while 循环检查条件，不能用 if —— 因为存在“虚假唤醒”（spurious wakeup）
所以 JDK 提供了更高层的抽象：
-
BlockingQueue（如LinkedBlockingQueue）：put()和take()自动处理阻塞与唤醒，一行代码搞定生产者-消费者 -
CountDownLatch：适合“等 N 个任务全部完成再继续”，比如启动服务时等待所有模块初始化完毕 -
CyclicBarrier：适合“多个线程互相等待到达某一点再一起往下走”，比如并行计算分片后的汇总阶段
这些类内部已封装了 wait/notify 的所有陷阱，直接用比手写安全得多。
真正难的从来不是“怎么起线程”，而是“哪些数据共享、怎么保护、线程怎么等、等谁、等多久”。并发程序的复杂度不在语法，而在状态流转的设计。稍不留神，死锁、活锁、可见性丢失就藏在看似正常的代码里。
