synchronized(this) 不一定安全，因其锁作用域仅限当前实例，无法保护静态资源，且在单例、继承、对象发布等场景下易导致锁边界失控，应改用私有final对象锁。
为什么 synchronized 块里用 this 不一定安全
当多个线程操作同一个对象实例时，synchronized(this) 能保证该对象内临界区互斥；但若类被设计为可被多个不同引用访问（比如 Spring 管理的单例 Bean），或方法被子类重写后暴露了锁对象，就可能让外部代码意外持有同一把锁，造成阻塞扩散或死锁风险。
更常见的是误以为 this 锁能保护静态资源——它完全无效，因为静态成员属于 Class 对象，不是实例。
- 只对当前实例有效，不作用于静态字段或其它实例
- 如果对象被发布到多处（如作为参数传入、放入集合、被监听器引用），锁的边界就不可控
- 推荐改用私有 final 对象锁：
private final Object lock = new Object();，明确锁的作用域
volatile 不能替代 synchronized 的三种典型场景
volatile 只保证可见性和禁止指令重排序，不提供原子性。以下情况它完全无法解决同步问题：
- 复合操作：如
counter++（读-改-写三步），即使counter是volatile，仍会丢失更新 - 依赖检查再执行（check-then-act）：如
if (list.isEmpty()) list.add(x);，判断和添加之间存在竞态窗口 - 多个变量协同变化：如
ready = true; data = 42;，仅给ready加volatile不能确保data对其他线程及时可见（需volatile+ happens-before 链，或用锁）
ReentrantLock 和 synchronized 的关键取舍点
两者都支持可重入，但行为差异直接影响编码方式和错误排查路径：
BJXSHOP网上购物系统 - 书店版
下载
BJXSHOP购物管理系统是一个功能完善、展示信息丰富的电子商店销售平台；针对企业与个人的网上销售系统；开放式远程商店管理；完善的订单管理、销售统计、结算系统；强力搜索引擎支持；提供网上多种在线支付方式解决方案；强大的技术应用能力和网络安全系统 BJXSHOP网上购物系统 - 书店版，它具备其他通用购物系统不同的功能，有针对图书销售而进行开发的一个电子商店销售平台，如图书ISBN，图书目录
立即学习“Java免费学习笔记（深入）”；
-
synchronized自动释放锁（JVM 保证），ReentrantLock必须显式在finally块中调用unlock()，漏写会导致永久阻塞 -
ReentrantLock支持公平锁（构造时传true），但性能显著下降；synchronized非公平且不可配置 -
ReentrantLock提供tryLock(long, TimeUnit)，可避免无限等待；synchronized无超时机制，只能靠中断配合wait() - 调试时，
synchronized的锁信息在 jstack 中显示为- locked，而ReentrantLock显示为java.util.concurrent.locks.AbstractQueuedSynchronizer$Node，定位更难
ConcurrentHashMap 的 size() 和 isEmpty() 为什么不准
ConcurrentHashMap 为高并发设计，内部采用分段锁或 CAS，size() 和 isEmpty() 返回的是**近似值**，不加全局同步就无法精确统计：
-
size()在 JDK 8+ 中是遍历所有 bin 并累加，但过程中其他线程可能正在增删，结果可能偏高或偏低 -
isEmpty()只检查第一个 bin 是否为空，其余段未扫描，返回true时未必真空 - 若业务强依赖精确大小（如限流、批处理终止条件），应改用
mappingCount()（返回long，仍是估算，但比size()更准），或引入额外计数器（用AtomicLong配合所有写操作）
Map<String, Integer> map = new ConcurrentHashMap<>();
// ❌ 不可靠
if (map.size() > 1000) {
// 可能刚过 1000 就被清空
}
<p>// ✅ 更稳妥（仍非绝对精确，但语义更清晰）
if (map.mappingCount() > 1000L) {
// ...
}锁的粒度、可见性边界、工具类的“近似性”——这些不是文档里写清楚就能避开的坑，而是每次加锁、每次读 volatile、每次调 size() 时，得在脑子里多问一句：“此刻我真正控制住什么？又放过了什么？”
