Shulou(Shulou.com)06/03 Report--

This article will explain in detail the example analysis of the Java lock mechanism for you. The editor thinks it is very practical, so I share it for you as a reference. I hope you can get something after reading this article.

1. Pessimistic lock and optimistic lock

We can roughly divide locks into two categories:

Pessimistic lock

Optimistic lock

As the name implies, pessimistic locks always assume the worst-case scenario, and every time they get data, they assume that other threads will modify it, so they lock it every time they get the data. in this way, other threads will be blocked until they acquire the lock when they want to modify the data. For example, table locks, row locks, read locks, write locks in MySQL database, synchronized and ReentrantLock in Java, etc.

The optimistic lock always assumes the best situation. Every time you get the data, you think that other threads will not modify it, so you will not lock it. However, when you modify the data, you need to judge whether any other thread has modified the data during this period. If it has not been modified, it will change normally. If it has been modified, the modification will fail. Common optimistic locks include version number control, CAS algorithm and so on.

2. Pessimistic lock application

The examples are as follows:

Public class LockDemo {static int count = 0; public static void main (String [] args) throws InterruptedException {List threadList = new ArrayList (); for (int I = 0; I

< 50; i++) { Thread thread = new Thread(() ->

{for (int j = 0; j)

< 1000; ++j) { count++; } }); thread.start(); threadList.add(thread); } // 等待所有线程执行完毕 for (Thread thread : threadList) { thread.join(); } System.out.println(count); }} 在该程序中一共开启了50个线程，并在线程中对共享变量count进行++操作，所以如果不发生线程安全问题，最终的结果应该是50000，但该程序中一定存在线程安全问题，运行结果为： 48634 若想解决线程安全问题，可以使用synchronized关键字： public class LockDemo { static int count = 0; public static void main(String[] args) throws InterruptedException { List threadList = new ArrayList(); for (int i = 0; i < 50; i++) { Thread thread = new Thread(() ->

{/ / use the synchronized keyword to solve thread safety issues synchronized (LockDemo.class) {for (int j = 0; j)

< 1000; ++j) { count++; } } }); thread.start(); threadList.add(thread); } for (Thread thread : threadList) { thread.join(); } System.out.println(count); }} 将修改count变量的操作使用synchronized关键字包裹起来，这样当某个线程在进行++操作时，别的线程是无法同时进行++的，只能等待前一个线程执行完1000次后才能继续执行，这样便能保证最终的结果为50000。 使用ReentrantLock也能够解决线程安全问题： public class LockDemo { static int count = 0; public static void main(String[] args) throws InterruptedException { List threadList = new ArrayList(); Lock lock = new ReentrantLock(); for (int i = 0; i < 50; i++) { Thread thread = new Thread(() ->

{/ / use the ReentrantLock keyword to solve thread safety problems lock.lock (); try {for (int j = 0; j)

< 1000; ++j) { count++; } } finally { lock.unlock(); } }); thread.start(); threadList.add(thread); } for (Thread thread : threadList) { thread.join(); } System.out.println(count); }} 这两种锁机制都是悲观锁的具体实现，不管其它线程是否会同时修改，它都直接上锁，保证了原子操作。 3、乐观锁应用 由于线程的调度是极其耗费操作系统资源的，所以，我们应该尽量避免线程在不断阻塞和唤醒中切换，由此产生了乐观锁。 在数据库表中，我们往往会设置一个version字段，这就是乐观锁的体现，假设某个数据表的数据内容如下： +----+------+----------+ ------- +| id | name | password | version |+----+------+----------+ ------- +| 1 | zs | 123456 | 1 |+----+------+----------+ ------- + 它是如何避免线程安全问题的呢？ 假设此时有两个线程A、B想要修改这条数据，它们会执行如下的sql语句： select version from e_user where name = 'zs';update e_user set password = 'admin',version = version + 1 where name = 'zs' and version = 1; 首先两个线程均查询出zs用户的版本号为1，然后线程A先执行了更新操作，此时将用户的密码修改为了admin，并将版本号加1，接着线程B执行更新操作，此时版本号已经为2了，所以更新肯定是失败的，由此，线程B就失败了，它只能重新去获取版本号再进行更新，这就是乐观锁，我们并没有对程序和数据库进行任何的加锁操作，但它仍然能够保证线程安全。 4、CAS 仍然以最开始做加法的程序为例，在Java中，我们还可以采用一种特殊的方式来实现它： public class LockDemo { static AtomicInteger count = new AtomicInteger(0); public static void main(String[] args) throws InterruptedException { List threadList = new ArrayList(); for (int i = 0; i < 50; i++) { Thread thread = new Thread(() ->

{for (int j = 0; j)

< 1000; ++j) { // 使用AtomicInteger解决线程安全问题 count.incrementAndGet(); } }); thread.start(); threadList.add(thread); } for (Thread thread : threadList) { thread.join(); } System.out.println(count); }} 为何使用AtomicInteger类就能够解决线程安全问题呢？ 我们来查看一下源码： public final int incrementAndGet() { return unsafe.getAndAddInt(this, valueOffset, 1) + 1;} 当count调用incrementAndGet()方法时，实际上调用的是UnSafe类的getAndAddInt()方法： public final int getAndAddInt(Object var1, long var2, int var4) { int var5; do { var5 = this.getIntVolatile(var1, var2); } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4)); return var5;} getAndAddInt()方法中有一个循环，关键的代码就在这里，我们假设线程A此时进入了该方法，此时var1即为AtomicInteger对象（初始值为0），var2的值为12（这是一个内存偏移量，我们可以不用关心），var4的值为1（准备对count进行加1操作）。 首先通过AtomicInteger对象和内存偏移量即可得到主存中的数据值： var5 = this.getIntVolatile(var1, var2); 获取到var5的值为0，然后程序会进行判断： !this.compareAndSwapInt(var1, var2, var5, var5 + var4) compareAndSwapInt()是一个本地方法，它的作用是比较并交换，即：判断var1的值与主存中取出的var5的值是否相同，此时肯定是相同的，所以会将var5+var4的值赋值给var1，并返回true，对true取反为false，所以循环就结束了，最终方法返回1。 这是一切正常的运行流程，然而当发生并发时，处理情况就不太一样了，假设此时线程A执行到了getAndAddInt()方法： public final int getAndAddInt(Object var1, long var2, int var4) { int var5; do { var5 = this.getIntVolatile(var1, var2); } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4)); return var5;} 线程A此时获取到var1的值为0（var1即为共享变量AtomicInteger），当线程A正准备执行下去时，线程B抢先执行了，线程B此时获取到var1的值为0，var5的值为0，比较成功，此时var1的值就变为1；这时候轮到线程A执行了，它获取var5的值为1，此时var1的值不等于var5的值，此次加1操作就会失败，并重新进入循环，此时var1的值已经发生了变化，此时重新获取var5的值也为1，比较成功，所以将var1的值加1变为2，若是在获取var5之前别的线程又修改了主存中var1的值，则本次操作又会失败，程序重新进入循环。 这就是利用自旋的方式来实现一个乐观锁，因为它没有加锁，所以省下了线程调度的资源，但也要避免程序一直自旋的情况发生。 5、手写一个自旋锁public class LockDemo { private AtomicReference atomicReference = new AtomicReference(); public void lock() { // 获取当前线程对象 Thread thread = Thread.currentThread(); // 自旋等待 while (!atomicReference.compareAndSet(null, thread)) { } } public void unlock() { // 获取当前线程对象 Thread thread = Thread.currentThread(); atomicReference.compareAndSet(thread, null); } static int count = 0; public static void main(String[] args) throws InterruptedException { LockDemo lockDemo = new LockDemo(); List threadList = new ArrayList(); for (int i = 0; i < 50; i++) { Thread thread = new Thread(() ->

{lockDemo.lock (); for (int j = 0; j < 1000; jacks +) {count++;} lockDemo.unlock ();}); thread.start (); threadList.add (thread) } / / wait for thread execution to finish for (Thread thread: threadList) {thread.join ();} System.out.println (count);}}

A spin lock can be easily implemented using the principle of CAS. First of all, the initial value in AtomicReference must be null, so the first thread will successfully put the object of the current thread into AtomicReference after calling the lock () method. If another thread calls the lock () method, it will fall into a loop waiting because the thread object is different from the object in AtomicReference until the first thread completes the + + operation and calls the unlock () method. Only then will the thread set the AtomicReference value to null, so that other threads can jump out of the loop.

Through the CAS mechanism, we can simulate the effect of locking without adding locks, but its disadvantages are also obvious:

Loop waiting takes up CPU resources

The atomic operation of only one variable is guaranteed.

It will cause ABA problems.

This is the end of the article on "sample Analysis of Java Lock Mechanism". I hope the above content can be helpful to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.