面试官在我们的开发过程中离不开锁也有很多锁相关的概念你能梳理下么面试者锁的话有乐观锁、悲观锁、读写锁还可以基于Mysql、Redis、ZK去实现分布式锁。面试官关于锁的概念有很多我们可以根据不同的维度去讲。第一个维度是从锁的“特性”来分可以分为乐观锁与悲观锁悲观锁​ 认为并发冲突是常态所以在操作数据前一定要先加锁。它的思想是“先保护再操作”。synchronized和ReentrantLock在独占模式下就是典型的悲观锁实现。乐观锁​ 认为并发冲突是偶然的所以先直接进行操作在提交更新时再检测冲突。它的思想是“先操作有冲突再解决”。最常见的实现方式是版本号机制或CAS操作。Java中的原子类如AtomicInteger就是基于CAS的乐观锁。第二个维度是从锁的“设计”与“竞争策略”来分可以分为公平锁与非公平锁这关系到锁的性能和公平性。公平锁​ 遵循先来后到的原则线程按照申请锁的顺序排队获取。优点是避免了线程饥饿缺点是整体吞吐量较低因为要维护一个队列。非公平锁​ 允许“插队”新来的线程有机会直接尝试获取锁获取不到再排队。优点是减少了线程切换的开销吞吐率高但可能导致某些线程长时间等待。ReentrantLock可以指定公平或非公平因为底层的aqs本来就有维护队列而synchronized是非公平锁。第三个维度是关于锁的“状态”和“可重复性”分为可重入锁与不可重入锁可重入锁​ 允许同一个线程在已经持有锁的情况下再次获取同一把锁。synchronized和ReentrantLock都是可重入锁。这可以防止线程自己把自己锁死。不可重入锁则相反线程不能重复获取锁如果使用不当就会造成死锁。所以java里面的锁基本上都是可重入锁第四个维度是从“共享性”来分这决定了锁的粒度。可以分为独占锁排他锁/写锁与共享锁读锁独占锁​ 一次只允许一个线程访问资源如ReentrantLock、synchronized。主要用于写操作。共享锁​ 允许多个线程同时访问资源如ReadWriteLock中的ReadLock。主要用于读操作。读写锁ReentrantReadWriteLock是这两种策略的经典结合遵循“读读共享读写互斥写写互斥”的原则能极大提升读多写少场景的性能。除了以上四个主要维度在实际的Java并发编程和源码中我们还会接触到一些更具体、更高级的锁概念自旋锁 当线程尝试获取锁失败时不会立即挂起而是循环重试自旋。这避免了线程切换的开销但会消耗CPU。适用于锁被持有时间很短的场景。CAS操作底层就隐含了自旋。自适应自旋锁 是自旋锁的优化自旋的时间不再固定而是由前一次在同一个锁上的自旋成功与否及持有者状态来决定更加智能。锁消除 是JIT编译器的优化当编译器检测到某段代码的锁不可能存在共享数据竞争时就会将这个锁“消除”掉。锁粗化 也是编译器的优化。如果虚拟机探测到一连串零碎的操作都对同一个对象反复加锁解锁会把加锁同步的范围“粗化”到整个操作序列的外部以减少不必要的性能损耗。偏向锁/轻量级锁/重量级锁 这是synchronized在JVM内部的锁升级机制是为了在无竞争和低竞争时减少性能开销。偏向锁 适用于只有一个线程访问的场景直接在对象头标记线程ID几乎无开销。轻量级锁 当有轻微竞争交替执行时通过CAS竞争锁失败则自旋尝试。重量级锁 当竞争激烈自旋失败会升级为基于操作系统互斥量Mutex的锁线程会进入阻塞队列进行用户态到内核态的切换开销最大。集群、微服务、分布式的区别面试官我看你的项目也是用的微服务架构也做了集群部署工作中也用到了分布式锁啥的。你能跟我讲下集群、微服务、分布式的区别么面试者 集群的话就是可以部署主从微服务的话就是做服务拆分做解耦分布式的话 服务拆分应该也属于分布式吧。面试官 OK这个看似是概念的问题但是面试官其实更希望结合你的经验、项目来去回答这个问题因为这些概念在工作中一定能接触到的。我跟你讲下我的理解。集群说白了就是“同一个服务多部署几份”。当一个服务扛不住压力了我就把它复制出来在多台机器上多跑几个实例。然后前面挂个负载均衡把流量均匀分给这些实例。它的核心就是“复制”和“分摊”专门解决“量不够”的问题提升处理能力防止一个实例挂了导致全瘫。微服务思路就不同了它不再是复制而是“拆分”。它把原来一个庞大复杂的单体应用按照不同的业务功能拆分成一堆小型、独立的服务。比如拆成用户服务、订单服务、支付服务。每个小服务都高度自治可以用自己的技术栈有自己的数据库能独立开发、测试、部署和伸缩运维。它们之间通过清晰的 API比如 REST 或 gRPC来通信协作。它的核心价值是提升“敏捷性”和“可维护性”让团队能并行开发快速迭代降低系统耦合度。当然微服务里的每个独立服务自己也可以用集群的方式来部署保证它自身的高可用。分布式这个概念更大是一个总称。简单理解只要一个系统的不同组件或功能是部署在多台机器/进程上需要通过网络通信来协同工作那它就是分布式的。像分布式锁、事务这些复杂问题之所以出现就是因为状态和操作“跨机器”了不再受单一程序控制。所以无论是集群多个相同服务实例协作还是微服务多个不同服务协作它们的具体架构模式都属于分布式系统这个大范畴总结一下关系集群侧重横向复制扩展解决单点瓶颈和可用性。微服务侧重业务拆分解耦解决复杂性和开发效率。分布式是涵盖集群、微服务的总体架构特征。