JunkFood读者说你文章不对,作者被鞭策后,DBA 开始研究JAVA程序锁
开头还是介绍一下群,如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题,有需求都可以加群群内有各大数据库行业大咖,可以解决你的问题。加群请联系 liuaustin3 ,(共2270人左右 1 + 2 + 3 + 4 +5 + 6) 新人奖直接分配到5群,开始建6群。
之前的一篇文章中,关于RC 和 RR 隔离级别的问题,在文章尾部建议在大部分场景下,为了高并发和性能的需求,我们都建议使用RC的数据库隔离级别。这里被读者指出,这样的建议是有问题的,基于这个事情,读者也给我一些建议。这里我也进行了一些研究。
这里首先感谢这位读者,同时在翻看了读者的给出的文章链接后,我也想更加深入,之前的确在不少金融机构工作过,也真的未见这些机构的数据库的隔离级别被强制为RR,同时ORACLE的隔离级别也只能使用RC,所以在这样的情况下,到底金融程序中是如何在使用RC数据库隔离级别的时候,还能避免幻读的。
在程序设计中,程序员口中经常会提到,乐观锁和悲观锁的概念,而程序员和DBA 之间,或者说DBA是否能理解程序设计中带有的乐观锁和悲观锁的概念。
在程序中的悲观锁被使用时,他会认为自己在使用数据的时候会有其他的线程来去使用它的数据或修改数据,所以在他使用数据的时候,会对数据进行加锁的工作,也就是他要修改什么什么程序会对这些数据进行加锁的处理,在JAVA程序中的synchronized 的关键字和 Lock的实现都是悲观锁的形式。
与其对应的是程序中的乐观锁,乐观锁认为自己在使用数据的时候,不会有别的线程来修改数据,对于自己线程使用的数据是不会程序进行加锁的处理,只是在更新数据的时候会去判断之前有没有线程更新数据,如果这个数据没有被更新则当前自己的线程修改数据是成功的,如果不是那么就会报重试或异常。
经过上面的信息的描述,程序本身针对自己的要使用的数据是有相关的数据锁的,
比如程序中的乐观锁实现的方式有如下的方式:
public class Widget {
public synchronized void doSomething() {
System.out.println("方法1执行...");
doOthers();
} public synchronized void doOthers() {
System.out.println("方法2执行...");
}
}