Java并发与线程模型详解

积累知识，胜过积蓄金银！毕竟在文章开发的过程中，会遇到各种各样的问题，往往都是一些细节知识点还没有掌握好而导致的，因此基础知识点的积累是很重要的。下面本文《Java并发基础与线程模型解析》，就带大家讲解一下知识点，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

本质区别在于对象模型与复用能力：继承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，多线程并发执行仍会导致结果丢失。

以下代码在高并发下大概率输出小于预期值：

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，优先检查是否锁范围过大，而不是纠结偏向锁是否开启。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。