Java引入synchronized后，为何还需额外设计Lock锁机制？

本文共计1580个文字，预计阅读时间需要7分钟。

Java中，synchronized和Lock都是用于解决并发编程中线程安全问题的重要工具。synchronized关键字可以保证代码块或方法的线程安全性，而Lock接口提供了更灵活的锁操作。

尽管synchronized已经能够满足许多线程同步的需求，Java仍然提供了Lock接口及其实现，如ReentrantLock，主要原因如下：

1. 更细粒度的控制：Lock提供了比synchronized更细粒度的锁控制，允许更复杂的锁定策略，如尝试非阻塞地获取锁、尝试在给定时间内获取锁等。

2. 公平性：Lock可以配置为公平锁，这意味着线程按照请求锁的顺序获取锁，而synchronized默认是非公平的。

3. 中断响应：Lock在等待锁的过程中可以响应中断，而synchronized在等待锁时不会响应中断。

4. 扩展性：Lock接口允许实现更复杂的锁定机制，如读写锁（ReadWriteLock），这在某些场景下比synchronized更高效。

因此，Lock接口并不是简单地重复造轮子，而是为了提供更全面、更灵活的并发控制机制。

众所周知，synchronized和Lock锁是java并发编程中两大利器，可以用来解决线程安全的问题。但是为什么Java有了synchronized之后还是提供了Lock接口这个api，难道仅仅只是重复造了轮子这么简单么？本文就来探讨一下这个问题。

谈到这个问题，其实很多同学第一反应都会说，Lock锁的性能比synchronized好，synchronized属于重量级的锁。