发布于2021-03-13 14:41 阅读(1267) 评论(0) 点赞(25) 收藏(3)
第一种:互斥同步也叫堵塞同步
第二种:非堵塞同步
第三种:无同步
第一种,互斥同步 使用synchronized Lock来实现。synchronized 曾经有偏向群,轻量级锁,重量级锁三个等级来优化。底层依靠编译器和虚拟机共同完成,也实现了等待队列。底层有三个队列,竞争队列,等待队列,优先队列。JUC的锁就不多说了。脑补。
区别一定清清楚楚:三个——中断,公平,锁可以绑定多个条件。详细解释如下:
主要有以下三项:等待可中断、可实现公 平锁及锁可以绑定多个条件。
·等待可中断:是指当持有锁的线程长期不释放锁的时候,正在等待的线程可以选择放弃等待,改 为处理其他事情。可中断特性对处理执行时间非常长的同步块很有帮助。
·公平锁:是指多个线程在等待同一个锁时,必须按照申请锁的时间顺序来依次获得锁;而非公平 锁则不保证这一点,在锁被释放时,任何一个等待锁的线程都有机会获得锁。synchronized中的锁是非 公平的,ReentrantLock在默认情况下也是非公平的,但可以通过带布尔值的构造函数要求使用公平锁。不过一旦使用了公平锁,将会导致ReentrantLock的性能急剧下降,会明显影响吞吐量。
·锁绑定多个条件:是指一个ReentrantLock对象可以同时绑定多个Condition对象。在synchronized 中,锁对象的wait()跟它的notify()或者notifyAll()方法配合可以实现一个隐含的条件,如果要和多于一个的条件关联的时候,就不得不额外添加一个锁;而ReentrantLock则无须这样做,多次调用 newCondition()方法即可
第二种,非堵塞同步主要是用了CAS的思想来实现。常用工具 |@Atomic的原子类|@为解决ABA问题而产生的AtomicStampedReference类。不过ABA大多数情况不影响业务,即使会影响也应该考虑第一种方案同步互斥方案来解决。
第三种,无同步,一种可重入。最典型的生产者消费者模型,都会将消费过程限制在一个线程中消费完。Web交互模型的Thread per Request的处理方式。这种方式可以使用线程本地存储方案来解决线程安全问题。
Thread Local Storage 方案典型实现,Java语言中,如果一个变量要被多线程访问,可以使用volatile关键字将它声明为“ 易变的”;如果
一个变量只要被某个线程独享,Java中就没有类似C++中__declspec(thread)[7]这样的关键字去修饰,不过我们还是可以通过java.lang.ThreadLocal类来实现线程本地存储的功能。每一个线程的Thread对象中都有一个ThreadLocalMap对象,这个对象存储了一组以ThreadLocal.threadLocalHashCode为键,以本地线程变量为值的K-V值对,ThreadLocal对象就是当前线程的ThreadLocalMap的访问入口,每一个
ThreadLocal对象都包含了一个独一无二的threadLocalHashCode值,使用这个值就可以在线程K-V值对中找回对应的本地线程变量。
1 同步互斥,非堵塞,无锁。
2 lock 等待中断,公平,多条件绑定。
3 为啥有用JUC ReenTrantLock? 你如果想要 等待中断,公平,多条件绑定时,就不用考虑synchronized了
原文链接:https://blog.csdn.net/qfzhangwei/article/details/114685294
作者:天天在家
链接:http://www.javaheidong.com/blog/article/114390/2d970769262e2d2113b1/
来源:java黑洞网
任何形式的转载都请注明出处,如有侵权 一经发现 必将追究其法律责任
昵称:
评论内容:(最多支持255个字符)
---无人问津也好,技不如人也罢,你都要试着安静下来,去做自己该做的事,而不是让内心的烦躁、焦虑,坏掉你本来就不多的热情和定力
Copyright © 2018-2021 java黑洞网 All Rights Reserved 版权所有,并保留所有权利。京ICP备18063182号-2
投诉与举报,广告合作请联系vgs_info@163.com或QQ3083709327
免责声明:网站文章均由用户上传,仅供读者学习交流使用,禁止用做商业用途。若文章涉及色情,反动,侵权等违法信息,请向我们举报,一经核实我们会立即删除!