Java多线程难点在于线程调度、内存可见性、锁语义和执行上下文；thread.run()是普通调用，start()才真正启新线程；synchronized锁对象而非代码；volatile不保证原子性；Future.get()会阻塞，需避免串行等待。
Java 多线程不是“开了多个 Thread 就算并发”，真正决定行为的是线程调度、内存可见性、锁语义和执行上下文——这些才是写错后难复现、难调试的根源。
Thread.start() 和 Runnable.run() 的区别不只是“是否新开线程”
调用 run() 是普通方法调用，仍在当前线程执行；start() 才触发 JVM 创建新 OS 线程并调度执行 run()。常见错误是误把 thread.run() 当作启动线程，结果逻辑串行执行，还查不出问题。
- 永远不要手动调用
thread.run()，除非你明确想在当前线程同步执行逻辑 -
start()只能调用一次，重复调用抛IllegalThreadStateException - 新建的
Thread对象未start()前，其getState()返回NEW，不是RUNNABLE
synchronized 锁的是对象，不是代码块或方法名
锁粒度取决于你传入的监视器（monitor）对象。静态方法锁的是类对象 MyClass.class，实例方法锁的是 this，而手动 synchronized(obj) 锁的是 obj 本身——哪怕 obj 是个临时 new 出来的对象，也完全不起作用。
- 避免
synchronized(new Object())：每次新建对象，锁不共享，等同于没锁 - 注意
String字面量会被常量池复用，synchronized("key")可能意外跨类互斥，极难排查 - 同步方法默认锁
this或类对象，但子类重写后若未同步，父类锁失效
volatile 不能替代 synchronized 的三个典型场景
volatile 仅保证变量的**可见性**和**禁止指令重排序**，不提供**原子性**。以下操作即使字段声明为 volatile，依然线程不安全：
-
counter++（读-改-写三步，非原子） - 基于值的条件判断再修改，如
if (flag) { doWork(); flag = false; } - 多个 volatile 变量之间存在逻辑依赖，如
data = 42; ready = true;—— 读线程可能看到ready == true但data还未刷新
这类场景必须用 synchronized、java.util.concurrent 工具类（如 AtomicInteger、CountDownLatch），或显式加锁控制临界区。
线程池 submit() 返回 Future，但 get() 会阻塞当前线程
很多人以为用了 ExecutorService 就“自动异步”，其实 Future.get() 是同步阻塞调用。如果在主线程反复调用 get() 等待多个任务，实际退化成串行执行，还占着线程资源。
- 避免在循环中逐个
future.get()，应先收集所有Future，再统一处理 - 使用
get(timeout, unit)设超时，防止无限等待 - 真正解耦应配合回调（如
CompletableFuture.thenApply()）或事件驱动模型，而非靠阻塞取结果
多线程里最麻烦的从来不是怎么开线程，而是状态怎么流转、谁负责清理、异常怎么传播、超时怎么判定——这些细节不在语法里，而在每个 join()、interrupt()、shutdownNow() 的调用时机中。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
