多线程核心价值是提升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 包都是为解决这个问题：
