Java

Java还有救吗？ 这个问题背后的情绪 每隔一段时间就会有"Java 已死"的讨论。坦白说，Java 确实有让人不爽的地方：代码冗长、启动慢、内存占用大、框架配置繁琐。和 Go 的简洁、Rust 的性能、Kotlin 的语法糖比起来，Java 显得有些老态龙钟。 但我觉得这问题的前提就错了——语言不是用来比的，是用来干活儿的。 Java 真正的竞争力是什么 三个字：生态、人才、兼容。 生态 Spring Boot、MyBatis、Netty、Kafka、Elasticsearch、Hadoop、Flink……几乎所有中间件和基础设施都对 Java 有一流支持。这不是一朝一夕能追赶的。 人才 Java 开发者的存量是其他语言难以比拟的。一个公司如果用 Go 或 Rust 创业，招人的难度和成本都会显著高于 Java。不是每个人都能为技术品味买单。 兼容 Java 的向后兼容性是业界标杆。十年前写的代码今天还能跑，这在一些业务场景中是无价之宝。银行、保险、政务这些行业的系统换代周期极长，Java 的稳定性就是核心竞争力。 Java 这几年的自救 Java 的演进速度最近明显加快了： Java 17/21 LTS：稳定可靠的新时代基线 虚拟线程（Project Loom）：彻底解决了"一个请求一个线程"的资源瓶颈，不需要再用 WebFlux 写回调地狱 Record 类：再也不用写 getter/setter/equals/hashCode 了 模式匹配 + switch 表达式：语法表达力大幅提升 Valhalla（值类型）：解决 Integer vs int 的装箱地狱，性能进一步提升 Panama（外部函数和内存 API）：告别 JNI 的噩梦 虚拟线程是真正意义上的 game changer——它能在一个 JVM 实例上跑数百万个轻量级线程，与 Go 的 goroutine 正面对标，还不需要破坏现有的 Thread API。 ...

《Java 并发编程的艺术》个人总结 为什么读这本书 工作中写并发代码的机会不少——线程池、缓存、异步处理——但遇到诡异的可见性问题或死锁时，往往只能靠加 synchronized 碰运气。这本书系统地梳理了 Java 内存模型和并发工具的设计原理，读完确实对调试并发问题有了更清晰的思路。 核心知识点梳理 1. 并发编程的挑战 书中开篇说的三个核心问题： 上下文切换：线程多了，CPU 花在切换上的时间比干活还多 死锁：互相等对方的锁 资源限制：硬件瓶颈不解决，加再多线程也没用 经验上，线程数 ≈ CPU 核数 × 2（取决于 IO 密集还是计算密集） 是一个比较可靠的起点。 2. Java 内存模型（JMM） 这是全书最重要的一章。JMM 控制的是一个线程对共享变量的写入何时对另一个线程可见。核心概念： happens-before 规则：程序顺序、volatile、锁、传递性等 volatile：保证可见性和禁止指令重排序，但不保证原子性 锁：synchronized 和 ReentrantLock 同时保证原子性和可见性 并发编程中大部分诡异 bug 的根因都是对 JMM 的理解不到位——以为一个线程写完了另一个线程就一定能读到。 3. 并发基础组件 组件 核心作用 使用场景 volatile 轻量级可见性保证 状态标识位 synchronized 互斥 + 可见性 临界区保护 ReentrantLock 可中断/超时/公平锁 需要灵活锁控制的场景 AtomicInteger/Long/Reference CAS 无锁原子操作 计数器、状态机 CountDownLatch 等待多个线程完成 并行任务汇总 CyclicBarrier 多个线程互相等待 分阶段并行计算 Semaphore 流量控制 限流、资源池 4. 线程池 ThreadPoolExecutor 的核心参数关系： ...