from http://blog.csdn.net/yongmi/article/details/8569886
首先来看同步方法的例子:
运行该程序输出结果为:
可以看到testSynchronizedMethod方法在两个线程之间同步执行。
如果此时将main方法修改为如下所示,则两个线程并不能同步执行,因为此时两个线程的同步监视器不是同一个对象,不能起到同步的作用。
此时输出结果如下所示:
若想修改后的main方法能够在两个线程之间同步运行,需要将testSynchronizedMethod方法声明为静态方法,这样两个线程的监视器是同一个对象(类对象),能够同步执行。修改后的代码如下所示:
输出结果如下:
同步块的情况与同步方法类似,只是同步块将同步控制的粒度缩小,这样能够更好的发挥多线程并行执行的效率。
使用this对象控制同一对象实例之间的同步:
输出结果:
使用class对象控制不同实例之间的同步:
输出结果:
使用synchronized关键字进行同步控制时,一定要把握好对象监视器,只有获得监视器的进程可以运行,其它都需要等待获取监视器。任何一个非null的对象都可以作为对象监视器,当synchronized作用在方法上时,锁住的便是对象实例(this);当作用在静态方法时锁住的便是对象对应的Class实例。
总结:
synchronized是通过软件(JVM)实现的,简单易用,即使在JDK5之后有了Lock,仍然被广泛地使用。
synchronized实际上是非公平的,新来的线程有可能立即获得监视器,而在等待区中等候已久的线程可能再次等待,不过这种抢占的方式可以预防饥饿。
synchronized只有锁只与一个条件(是否获取锁)相关联,不灵活,后来Condition与Lock的结合解决了这个问题。
多线程竞争一个锁时,其余未得到锁的线程只能不停的尝试获得锁,而不能中断。高并发的情况下会导致性能下降。ReentrantLock的lockInterruptibly()方法可以优先考虑响应中断。 一个线程等待时间过长,它可以中断自己,然后ReentrantLock响应这个中断,不再让这个线程继续等待。有了这个机制,使用ReentrantLock时就不会像synchronized那样产生死锁了。
参考资料: