在并发编程中常用到 synchronized 以及 ReentrantLock 锁，在业务开发过程中也可能会用到分布式锁，分布式锁常用框架的就是基于 Redis 实现的分布式锁框架 Redisson 和 基于 Zookeeper 实现的分布式锁框架 Curator。当然，也有其他的锁实现方式，在这里不做介绍。

如果不是踩到坑，我估计到现在还不知道时间字段会四舍五入。

最近遇到一个小伙伴问前端枚举转换问题，才意识到可以通过转换器（Converter）自动将前端传入的字段值使用枚举接收。

近期在 Mapper 中写了个方法重载，然后死活查不到正确结果，最终灵机一动，想到是不是因为重载，然后我 `Shift + F6` 把重载方法名字改了一下！结果，显而易见，重载的那个方法也一块改了。再次躺坑！

在 JDK 中有很多锁，包括 synchronized、ReentrantLock、ReentrantReadWriteLock、锁的使用场景也分很多种，下面看一下对加锁优化的小技巧。

Curator 同样支持分布式读写锁 和联锁，只需要使用 InterProcessReadWriteLock 即可，来一起看看它的源码以及实现方式。

分布式信号量，之前在 Redisson 中也介绍过，Redisson 的信号量是将计数维护在 Redis 中的，那现在来看一下 Curator 是如何基于 ZooKeeper 实现信号量的。

在了解了加锁和锁重入之后，最需要了解的还是在分布式场景下或者多线程并发加锁是如何处理的？

加锁逻辑已经介绍完毕，那当一个线程重复加锁是如何处理的呢？

一般工作中常用的分布式锁，就是基于 Redis 和 ZooKeeper，前面已经介绍完了 Redisson 锁相关的源码，下面一起看看基于 ZooKeeper 的锁。也就是 Curator 这个框架。

Redisson 还支持可重入读写锁，允许在分布式场景下，同时有多个读锁和一个写锁处于加锁状态。

Redisson 除了提供了分布式锁之外，还额外提供了同步组件，Semaphore 和 CountDownLatch。