重入锁ReentrantLock

2016-07-17 开源思想碰撞的思绪

Hi Alan，到家这么晚了，今天也没有实质性的研究东西；只好把今天与友人的趣事说下吧，哈哈。。。

人在于行走，接触外面的喧哗世界。这样，你的所见所闻以及你的思想大脑会有不一样的收获。所以，决定去找有人耍耍；技术的我们见了面还能聊啥，你们懂的；然后还是技术回归；交流设想场景下的锁机制的应用，其中，谈到java中的重入锁和redis 分布式锁。

分布式锁在分布式应用当中是要经常用到的，主要是解决分布式资源访问冲突的问题。
一开始考虑采用ReentrantLock来实现，但是实际上去实现的时候，是有问题的，ReentrantLock的lock和unlock要求必须是在同一线程进行，而分布式应用中，lock和unlock是两次不相关的请求，因此肯定不是同一线程，因此导致无法使用ReentrantLock。

该篇简单介绍下ReentrantLock（有兴趣的可以深入研究Java concurrent中的任务调度）：

重入锁（ReentrantLock）是一种递归无阻塞的同步机制。
Java官方的解释：“如果该锁定被另一个线程保持，则出于线程调度的目的，禁用当前线程，并且在获得锁定之前，该线程将一直处于休眠状态”。

对于ReentrantLock的场景如下：

场景1：如果发现该操作已经在执行中则不再执行（有状态执行）

a、用在定时任务时，如果任务执行时间可能超过下次计划执行时间，确保该有状态任务只有一个正在执行，忽略重复触发。
b、用在界面交互时点击执行较长时间请求操作时，防止多次点击导致后台重复执行（忽略重复触发）。

以上两种情况多用于进行非重要任务防止重复执行，（如：清除无用临时文件，检查某些资源的可用性，数据备份操作等）

场景2：如果发现该操作已经在执行，等待一个一个执行（同步执行，类似synchronized）

这种比较常见大家也都在用，主要是防止资源使用冲突，保证同一时间内只有一个操作可以使用该资源。
但与synchronized的明显区别是性能优势（伴随jvm的优化这个差距在减小）。同时Lock有更灵活的锁定方式，公平锁与不公平锁，而synchronized永远是公平的。

这种情况主要用于对资源的争抢（如：文件操作，同步消息发送，有状态的操作等）

ReentrantLock默认情况下为不公平锁

场景3：如果发现该操作已经在执行，则尝试等待一段时间，等待超时则不执行（尝试等待执行）

这种其实属于场景2的改进，等待获得锁的操作有一个时间的限制，如果超时则放弃执行。
用来防止由于资源处理不当长时间占用导致死锁情况（大家都在等待资源，导致线程队列溢出）。

场景4：如果发现该操作已经在执行，等待执行。这时可中断正在进行的操作立刻释放锁继续下一操作。

synchronized与Lock在默认情况下是不会响应中断(interrupt)操作，会继续执行完。lockInterruptibly()提供了可中断锁来解决此问题。（场景2的另一种改进，没有超时，只能等待中断或执行完毕）

这种情况主要用于取消某些操作对资源的占用。如：（取消正在同步运行的操作，来防止不正常操作长时间占用造成的阻塞）

详细请查看此连接http://my.oschina.net/noahxiao/blog/101558

《为你而厨·Meet》