lock锁实际使用场景
场景1：如果发现该操作已经在执行中则不再执行（有状态执行）
a、用在定时任务时，如果任务执行时间可能超过下次计划执行时间，确保该有状态任务只有一个正在执行，忽略重复触发。
b、用在界面交互时点击执行较长时间请求操作时，防止多次点击导致后台重复执行（忽略重复触发）。
以上两种情况多用于进行非重要任务防止重复执行，（如：清除无用临时文件，检查某些资源的可用性，数据备份操作等）
场景2：如果发现该操作已经在执行，等待一个一个执行（同步执行，类似synchronized）
这种比较常见大家也都在用，主要是防止资源使用冲突，保证同一时间内只有一个操作可以使用该资源。
但与synchronized的明显区别是性能优势（伴随jvm的优化这个差距在减小）。同时Lock有更灵活的锁定方式，公平锁与不公平锁，而synchronized永远是公平的。
这种情况主要用于对资源的争抢（如：文件操作，同步消息发送，有状态的操作等）
ReentrantLock默认情况下为不公平锁
场景3：如果发现该操作已经在执行，则尝试等待一段时间，等待超时则不执行（尝试等待执行）
jdk5发布时间
2004年9月
2004年9月发布了JDK5,之后所有的新版本都以JDK xxx方式命名,新增了自动装箱、泛型、动态注解、枚举、可变长参数、遍历循环(foreach循环);改进了Java的内存模型(Java Memory Model,JMM);提供了
到此，以上就是小编对于jvm中的锁的问题就介绍到这了，希望介绍的2点解答对大家有用，有任何问题和不懂的，欢迎各位老师在评论区讨论，给我留言。
微信扫一扫打赏
