java synchronization

synchronized和lock的用法区别
synchronized和lock性能区别
Refer

First, the difference between the usage of synchronized and lock

synchronized:在需要同步的对象中加入此控制,synchronized可以加在方法上,也可以加在特定代码块中,括号中表示需要锁的对象。

Introduction to synchronized

synchronized关键字通过修饰一个方法或声明一个代码块,从而产生一个同步对象锁以及对应的同步代码块。

每当有线程要对该同步代码块进行访问时,线程就会首先尝试去获取该对象锁,并在成功获取到对象锁后,对该同步代码块进行正常访问,在同步代码块访问过程中,线程会一直持有该对象锁直到同步代码块访问完毕才会释放。

在上述线程持有同步锁并进行同步代码块访问过程中,其它线程将无法获得该对象锁,也无法访问该同步代码,这些线程都会被阻塞直到上述线程访问完毕。syschronized关键字,通过以上措施,确保每次只有一个线程能持有对象锁并对同步代码块进行访问,并在访问结束之前,不会有其它线程对其进行访问。

也就说,即使同步代码块在执行过程中遭遇线程调度,其它线程也无法访问该同步代码块,直到该线程被重新调度并完成同步代码块的访问并释放对象锁。

这样就保证了线程对同步代码块访问的连续性不受线程调度而中断。

Synchronized is called a heavyweight lock, and its synchronization includes:

对于普通方法同步,锁是当前实例对象
对于静态方法同步,锁是当前类的 Class 对象
对于方法块同步,锁是 Synchronized 括号里的对象

上述都是对象级别的锁,当一个线程访问对象中的同步方法时,会获取到对象级别的锁,由于 Synchronized 内部是可重入的互斥锁,所以线程可再次重入用 Synchronized 修饰的方法,但当其它线程执行同一个对象的带有 Synchronized 的方法时,会被阻塞,即使和以持有对象锁的线程执行的相同对象的不同 Synchronized 方法。因为锁是对象级别的。比如线程 A、B。对象 Foo 有同步方法 M、N。线程 A 首先执行同步方法 M 时就会获取对象锁,此时 B 不能执行同一把对象锁修饰的方法 M、N。除非 A 释放锁。又因为锁是可重入的,所以 A 可以继续执行 M,N 方法。可重入锁一定程度上避免了死锁的问题,内部是关联一个计数器,加一次锁计数器值加一,为零时释放锁。

lock:需要显示指定起始位置和终止位置。一般使用ReentrantLock类做为锁,多个线程中必须要使用一个ReentrantLock类做为对象才能保证锁的生效。且在加锁和解锁处需要通过lock()和unlock()显示指出。所以一般会在finally块中写unlock()以防死锁。

ReentrantLock 拥有Synchronized相同的并发性和内存语义,此外还多了 锁投票,定时锁等候和中断锁等候

线程A和B都要获取对象O的锁定,假设A获取了对象O锁,B将等待A释放对O的锁定,

如果使用 synchronized ,如果A不释放,B将一直等下去,不能被中断

如果 使用ReentrantLock,如果A不释放,可以使B在等待了足够长的时间以后,中断等待,而干别的事情

ReentrantLock获取锁定与三种方式:

a) lock(), if the lock is acquired, it will return immediately. If another thread holds the lock, the current thread will sleep until the lock is acquired.

b) tryLock(), returns true immediately if the lock is acquired, and false if another thread is holding the lock.

c) tryLock(long timeout, TimeUnit unit), if the lock is acquired, it will return true immediately. If another thread is holding the lock, it will wait for the time given by the parameter. During the waiting process, if the lock is acquired, it will return true , if the wait times out, return false.

d) lockInterruptibly: If the lock is acquired, it returns immediately. If the lock is not acquired, the current thread sleeps until the lock is acquired, or the current thread is interrupted by another thread.

Second, the difference between synchronized and lock performance

1. There is no difference between the synchronized primitive and ReentrantLock in general, but in very complex synchronization applications, please consider using ReentrantLock, especially when you encounter the following two requirements.

某个线程在等待一个锁的控制权的这段时间需要中断
需要分开处理一些wait-notify,ReentrantLock里面的Condition应用,能够控制notify哪个线程
具有公平锁功能,每个到来的线程都将排队等候

2. Synchronized is implemented at the JVM level. Not only can the synchronized lock be monitored through some monitoring tools, but also when an exception occurs during code execution, the JVM will automatically release the lock, but using Lock will not work. Lock is implemented through code. To ensure that the lock will be released, you must put unLock() in finally{}

3. When the resource competition is not very fierce, the performance of Synchronized is better than that of ReetrantLock, but when the competition for resources is very fierce, the performance of Synchronized will drop dozens of times, but the performance of ReetrantLock can maintain normal;

synchronized:

在资源竞争不是很激烈的情况下,偶尔会有同步的情形下,synchronized是很合适的。原因在于,编译程序通常会尽可能的进行优化synchronize,另外可读性非常好,不管用没用过5.0多线程包的程序员都能理解。

ReentrantLock:

ReentrantLock提供了多样化的同步,比如有时间限制的同步,可以被Interrupt的同步(synchronized的同步是不能Interrupt的)等。在资源竞争不激烈的情形下,性能稍微比synchronized差点点。但是当同步非常激烈的时候,synchronized的性能一下子能下降好几十倍。而ReentrantLock确还能维持常态。

Atomic:

和上面的类似,不激烈情况下,性能比synchronized略逊,而激烈的时候,也能维持常态。激烈的时候,Atomic的性能会优于ReentrantLock一倍左右。但是其有一个缺点,就是只能同步一个值,一段代码中只能出现一个Atomic的变量,多于一个同步无效。因为他不能在多个Atomic之间同步。

Refer

1. In-depth study of the difference and usage of Java Synchronize and Lock

2. The difference between Lock and synchronized

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325898460&siteId=291194637
Recommended