public synchronized void addValue() {
// 线程安全的代码
}
2.1 方法同步与代码块同步的选择策略
实际开发中经常面临一个选择：到底该同步整个方法还是只同步关键代码块？这个决定直接影响着程序的性能和并发能力。
方法同步写起来简单直接，但锁的粒度较粗。如果方法中有大量不需要同步的操作，其他线程就得白白等待。代码块同步虽然多写几行代码，但能精确控制同步范围，只锁住真正需要保护的核心逻辑。
我参与过一个电商项目，商品库存扣减最初用的是方法同步。后来发现性能瓶颈出现在高并发场景，改成代码块同步后，只锁住库存计算的核心部分，性能提升了近三成。这种优化在业务高峰期效果特别明显。
一般来说，如果方法中只有少量操作需要同步，优先考虑代码块同步。如果整个方法都需要保护，方法同步的简洁性更有优势。具体选择还要结合业务场景和性能要求来权衡。
2.2 对象锁与类锁的区别与使用场景
对象锁和类锁是synchronized中容易混淆的概念。对象锁锁的是具体的对象实例，每个new出来的对象都有自己独立的锁。类锁锁的是类的Class对象，整个JVM中只有一份。
实例方法上的synchronized使用的是对象锁，不同实例之间互不干扰。静态方法上的synchronized使用的是类锁，会影响到该类的所有实例。
曾经有个同事在静态方法中调用了实例同步方法，结果出现了意料之外的阻塞。排查后发现是对象锁和类锁的嵌套使用导致了复杂的锁竞争。这种情况在复杂业务中并不少见。
对象锁适合保护实例级别的数据，比如用户的账户余额。类锁适合保护全局配置、静态缓存这类共享资源。理解这个区别能避免很多潜在的并发问题。
2.3 避免死锁的编程实践
死锁就像交通堵塞，多个线程互相等待对方释放锁，结果谁都动不了。实际开发中死锁往往出现在复杂的锁嵌套场景。
避免死锁有几个实用技巧：尽量按固定顺序获取锁，减少嵌套锁的层数，使用带超时的锁获取机制。这些方法都能有效降低死锁风险。
我遇到过最典型的死锁案例是两个线程互相等待对方持有的锁。线程A先锁住资源X再请求资源Y，线程B先锁住资源Y再请求资源X。这种循环等待最终导致系统卡死。
使用jstack等工具可以检测死锁，但更好的做法是在编码阶段就预防。保持锁的获取顺序一致，避免在持有一个锁的情况下去请求另一个锁。实在需要多个锁时，考虑使用更高级的并发工具替代。
死锁问题往往在测试阶段难以发现，到了生产环境才暴露。养成良好的锁使用习惯，比事后排查要省心得多。
3.1 synchronized的性能瓶颈分析
synchronized在早期Java版本中确实存在性能问题，每次加锁解锁都要涉及用户态到内核态的切换。这种重量级操作在高并发场景下会成为明显的性能瓶颈。
现代JVM已经做了很多优化，比如锁升级机制。当没有竞争时，synchronized只是个轻量级的偏向锁。出现竞争后才逐步升级为轻量级锁、重量级锁。这个优化让synchronized在低竞争环境下表现相当不错。
但高并发场景下问题依然存在。我维护过一个消息处理系统，在业务高峰期监控到大量线程阻塞在同一个synchronized方法上。线程频繁地在运行态和阻塞态之间切换，CPU时间大量消耗在上下文切换上，实际处理业务的效率反而很低。
另一个常见瓶颈是锁的持有时间过长。有些开发者在synchronized代码块中执行数据库查询、网络请求等耗时操作，这会让其他线程等待时间呈指数级增长。锁的粒度太粗，就像只有一个收银台的超市，顾客排起长队也就不奇怪了。
3.2 锁优化技巧与替代方案
优化synchronized性能可以从几个角度入手。首先是减小锁的粒度，能用代码块同步就不用方法同步。其次是缩短锁的持有时间，把非必要的操作移到同步块外部。
读写分离是个很实用的技巧。如果业务场景适合，考虑使用ReadWriteLock替代synchronized。它允许多个线程同时读，写操作才需要互斥。这种设计在读多写少的场景下性能提升非常显著。
我记得重构过一个配置管理系统，原本用synchronized保护所有配置操作。分析发现95%的请求都是读取配置，改成ReadWriteLock后，并发读取能力直接提升了五倍以上。
对于更复杂的并发场景，Java并发包提供了丰富的替代方案。ConcurrentHashMap适合替代需要同步的Map，Atomic系列类可以处理简单的原子操作。这些工具在底层做了大量优化，比手动使用synchronized要高效得多。
在某些极端性能要求的场景下，甚至可以考虑无锁编程。但无锁实现的复杂度较高，需要谨慎评估投入产出比。一般来说，先优化现有的synchronized使用，再考虑替换方案是比较稳妥的做法。
3.3 企业级项目中的synchronized使用规范
在企业级项目中，synchronized的使用需要遵循一定的规范。首要原则是明确锁的范围和目的，每个synchronized块都应该有清晰的保护目标。
代码审查时要特别关注锁的嵌套使用。多层锁嵌套不仅容易引发死锁，还会让代码逻辑变得难以理解。我们团队要求嵌套层数不能超过两层，超过就需要重新设计。
日志记录也很重要。在关键的同步块入口和出口添加适当的日志，能帮助后续的性能分析和问题排查。但要注意日志输出本身不能成为性能瓶颈，可以考虑使用异步日志或采样记录。
我参与制定的一个规范是“锁文档化”。每个synchronized的使用都要在注释中说明保护的是什么资源，预期的并发场景，以及可能的风险。这个习惯让后续维护轻松很多。
性能监控不可或缺。通过APM工具监控锁的等待时间、竞争情况，能及时发现潜在的并发问题。设定合理的阈值，当锁竞争超过一定程度时自动告警。
最后要记住，synchronized只是并发控制的工具之一。选择最合适的并发方案，而不是习惯性地使用synchronized，这才是高级开发者应有的思维方式。
