Java on BIT & 42

Java还有救吗？

Sat, 14 Mar 2026 00:00:00 +0000

每隔一段时间就会有"Java 已死"的讨论。坦白说，Java 确实有让人不爽的地方：代码冗长、启动慢、内存占用大、框架配置繁琐。和 Go 的简洁、Rust 的性能、Kotlin 的语法糖比起来，Java 显得有些老态龙钟。

但我觉得这问题的前提就错了——语言不是用来比的，是用来干活儿的。

三个字：生态、人才、兼容。

Spring Boot、MyBatis、Netty、Kafka、Elasticsearch、Hadoop、Flink……几乎所有中间件和基础设施都对 Java 有一流支持。这不是一朝一夕能追赶的。

Java 开发者的存量是其他语言难以比拟的。一个公司如果用 Go 或 Rust 创业，招人的难度和成本都会显著高于 Java。不是每个人都能为技术品味买单。

Java 的向后兼容性是业界标杆。十年前写的代码今天还能跑，这在一些业务场景中是无价之宝。银行、保险、政务这些行业的系统换代周期极长，Java 的稳定性就是核心竞争力。

Java 的演进速度最近明显加快了：

虚拟线程是真正意义上的 game changer——它能在一个 JVM 实例上跑数百万个轻量级线程，与 Go 的 goroutine 正面对标，还不需要破坏现有的 Thread API。

Sat, 23 Mar 2024 00:00:00 +0000

工作中写并发代码的机会不少——线程池、缓存、异步处理——但遇到诡异的可见性问题或死锁时，往往只能靠加 synchronized 碰运气。这本书系统地梳理了 Java 内存模型和并发工具的设计原理，读完确实对调试并发问题有了更清晰的思路。

书中开篇说的三个核心问题：

经验上，线程数 ≈ CPU 核数 × 2（取决于 IO 密集还是计算密集） 是一个比较可靠的起点。

这是全书最重要的一章。JMM 控制的是一个线程对共享变量的写入何时对另一个线程可见。核心概念：

并发编程中大部分诡异 bug 的根因都是对 JMM 的理解不到位——以为一个线程写完了另一个线程就一定能读到。

组件	核心作用	使用场景
`volatile`	轻量级可见性保证	状态标识位
`synchronized`	互斥 + 可见性	临界区保护
`ReentrantLock`	可中断/超时/公平锁	需要灵活锁控制的场景
`AtomicInteger/Long/Reference`	CAS 无锁原子操作	计数器、状态机
`CountDownLatch`	等待多个线程完成	并行任务汇总
`CyclicBarrier`	多个线程互相等待	分阶段并行计算
`Semaphore`	流量控制	限流、资源池

ThreadPoolExecutor 的核心参数关系：