最近看公司以前的代码,现在给出大致的结构
}为什么里面还要在有一个synchronize(threadLock),如果一个线程执行deal方法,就要获得demo实例的对象锁,才会执行,执行那个代码块需要获得threadLock的对象锁,个人认为没有必要在加这个锁吧。本来外面方法就是同步的。
哪位懂的话解释一下,谢谢。
有必要,就是在synchronized this的前提下还有同步竞争,比如说同一个对象里头还有东西要做竞争。
同步竞争 后还是只是一个线程进入方法内啊,能举个例子说一下吗
谢谢,我明白了,刚才看了一下的确是别的方法里还有同样的操作,所以就加了这样一个锁。我只注意了外面的嵌套。
版权声明:本文为博主原创文章,未经博主允许不得转载。 /u/article/details/
Synchronize对一般方法的修饰和对代码块的修饰没有什么区别,对代码块的修饰作用范围是Synchronize(this){ // 作用范围},大括号中的代码是作用范围,而对方法修饰的作用范围就是整个方法。如果把代码块中的代码提出来作为一个方法二者没有什么本质上的区别。
除了对一般方法修饰Synchronize还可以对静态方法进行修饰,我们知道类中的静态方法是属于所有实例化的对象的,可以推断如果Synchronize修饰一个静态方法那么该类所有实例化出来的对象对这个方法都是线程同步的。通过如下的实例验证:
本次虽然也是实例化的两个线程类,但是运行的结果却和只有一个线程实例类是一样的,因为在run中调用的是test这个静态的方法,这个方法时属于所有的对象,所以即使实例化的三个线程类,它们还是保持同步的。
JDK1.5中,synchronized是性能低效的。因为这是一个重量级操作,它对性能最大的影响是阻塞的是实现,挂起线程和恢复线程的操作都需要转入内核态中完成,这些操作给系统的并发性带来了很大的压力。相比之下使用Java提供的Lock对象,性能更高一些。多线程环境下,synchronized的吞吐量下降的非常严重,而ReentrankLock则能基本保持在同一个比较稳定的水平上。
到了JDK1.6,发生了变化,对synchronize加入了很多优化措施,有自适应自旋,锁消除,锁粗化,轻量级锁,偏向锁等等。导致在JDK1.6上synchronize的性能并不比Lock差。官方也表示,他们也更支持synchronize,在未来的版本中还有优化余地,所以还是提倡在synchronized能实现需求的情况下,优先考虑使用synchronized来进行同步。
基本语法上,ReentrantLock与synchronized很相似,它们都具备一样的线程重入特性,只是代码写法上有点区别而已,一个表现为API层面的互斥锁(Lock),一个表现为原生语法层面的互斥锁(synchronized)。ReentrantLock相对synchronized而言还是增加了一些高级功能,主要有以下三项: