本质区别在于对象模型与复用能力：继承Thread占用单继承位且任务绑定，Runnable是纯行为抽象，支持多线程复用和ExecutorService集成。
Java线程创建的两种方式本质区别在哪
直接继承 Thread 类和实现 Runnable 接口，表面看只是写法不同，实际影响的是对象模型与复用能力。继承 Thread 会占用唯一的类继承位，且每个 Thread 实例绑死一个任务；而 Runnable 是纯行为抽象，可被多个线程复用，也便于后续接入 ExecutorService。
常见错误是把 new Thread(runnable).start() 写成 new Thread(runnable).run()——后者只是普通方法调用，不会启动新线程，也不会触发 JVM 的线程调度。
-
Thread子类中重写的run()方法，若未调用super.run()，会丢失父类对Runnable的委托逻辑 - 使用
Lambda表达式创建Runnable时，注意捕获的局部变量必须是final或“事实 final” - Android 等受限环境里，
Thread构造函数可能被禁止，强制走HandlerThread或Executor
volatile 关键字不能保证原子性的典型场景
volatile 只保证可见性与禁止指令重排序，不提供原子性。最常踩坑的是自增操作：counter++ 实际包含“读取-修改-写入”三步，即使 counter 是 volatile，多线程并发执行仍会导致结果丢失。
以下代码在高并发下大概率输出小于预期值：
立即学习“Java免费学习笔记（深入）”；
public class VolatileCounter {
volatile int counter = 0;
void increment() { counter++; } // 非原子
}
替代方案取决于场景：
- 简单计数 → 改用
AtomicInteger的incrementAndGet() - 复合逻辑（如先判断再更新）→ 用
synchronized或ReentrantLock - 需要避免锁开销且逻辑允许 → 使用
StampedLock的乐观读
线程池拒绝策略的实际选择依据
当 ThreadPoolExecutor 的工作队列满、线程数已达 maximumPoolSize 时，新任务触发拒绝策略。默认的 AbortPolicy 直接抛 RejectedExecutionException，但线上服务往往需要更可控的降级行为。
四种内置策略的行为差异直接影响系统韧性：
-
CallerRunsPolicy：由提交任务的线程自己执行该任务 → 降低提交速率，适合突发流量但不允许丢任务的场景 -
DiscardPolicy：静默丢弃 → 适合日志采集等非关键任务 -
DiscardOldestPolicy：丢弃队列头任务，再尝试提交当前任务 → 适合有明显时效性的任务（如实时行情推送） - 自定义策略可记录监控指标（如丢弃数、触发时间），但要注意避免在拒绝路径里做耗时操作，否则会阻塞
execute()调用方
synchronized 锁升级过程对性能的真实影响
JVM 对 synchronized 的锁优化（偏向锁 → 轻量级锁 → 重量级锁）不是固定流程，而是基于运行时竞争情况动态决策。JDK 15+ 默认禁用偏向锁，因为现代应用中对象生命周期短、线程竞争频繁，偏向锁反而增加撤销开销。
真正影响性能的是锁粒度和持有时间：
- 在
ArrayList的add()方法上加synchronized，比在业务 service 方法上加锁更易引发争用 - 锁内执行 HTTP 调用或数据库查询，会把线程长时间挂起，导致其他线程排队等待，此时锁升级为重量级锁几乎是必然
- 用
jstack查看线程堆栈时，看到java.lang.Thread.State: BLOCKED (on object monitor)就说明已进入重量级锁等待
锁升级本身不慢，慢的是线程上下文切换和调度延迟。如果发现大量线程卡在 BLOCKED，优先检查是否锁范围过大，而不是纠结偏向锁是否开启。
