synchronized不能直接作用于lambda表达式本身，因其本质是函数式接口实例；实际同步需依赖lambda捕获的共享引用对象（如this、static对象或显式lock），锁粒度由该对象的生命周期和共享范围决定。
synchronized 不能直接作用于 Lambda 表达式本身，因为 Lambda 不是方法声明，也不是可被修饰的语法单元；它本质是一个函数式接口的实例对象。所谓“对 Lambda 加 synchronized”，实际只能是对 Lambda 所在的执行上下文（如调用它的方法）加锁，或显式地对某个锁对象（包括闭包捕获的对象）进行同步控制。
锁对象必须是明确、稳定、共享的引用类型
Lambda 表达式内部若访问外部局部变量（如 int count），该变量必须是 final 或“事实 final”——但这类变量是值拷贝，无法作为锁对象。只有捕获的 引用类型变量（如 Object lock = new Object()、this、静态对象、集合等）才可能成为有效锁目标：
- 若 Lambda 捕获的是一个
private final Object lock，且多个线程共用同一实例，则锁粒度取决于该对象的生命周期和共享范围 - 若每次调用都新建锁对象（如
() -> synchronized(new Object()) { ... }），则完全无同步效果——每个线程锁不同对象，互不干扰 - 捕获
this是常见做法，此时锁粒度等同于“实例锁”，适用于保护该对象的实例状态
闭包对象的锁粒度取决于其引用来源
Lambda 的闭包环境不生成新类或新锁机制，它只是隐式持有对外围变量的引用。关键看这些引用是否指向同一个 JVM 对象实例：
- 静态字段或单例对象 → 类级别锁粒度，全局串行化
- 实例字段（非 static）→ 实例级别锁粒度，同实例线程互斥，不同实例无影响
- 方法内新建对象（如
new Object()）→ 无实际同步意义，锁对象不共享 - 使用
ConcurrentHashMap等并发容器做键控锁（如locks.computeIfAbsent(key, k -> new Object())）→ 可实现键级细粒度锁，但需注意锁对象泄漏与 GC 友好性
字节码层面没有“Lambda 同步”指令
反编译可见：Lambda 被编译为私有静态方法 + invokedynamic 引导，其内部同步块仍由 monitorenter/monitorexit 指令实现，锁目标仍是某个明确的引用表达式。JVM 不识别“Lambda 本体”为锁主体，只认对象头中的 mark word 和 monitor 状态。
因此，评估锁粒度时，不要聚焦 Lambda 语法形式，而应追踪它所使用的锁对象的创建位置、作用域、共享方式和生命周期——这才是决定并发行为的真实依据。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
