多线程之JUC笔记

JUC并发包是jdk提供的一系列关于并发框架的jar包,最基本的有Lock和Condition,对应sychronized和wait&notify的功能,其核心是AQS抽象队列同步器。

AQS

AQS抽象队列同步器维护着一个FIFO阻塞同步队列,还有一个内部类ConditionObject,一个FIFO等待队列,它们的基本数据结构都是一个Node类。Node主要有prev,next,nextWaiter,waitStatus这些属性。此外还有一个state记录锁次数,owner记录当前获取锁的线程。下面以Reentrantlock来分析具体过程。

lock()

首先会使用cas操作尝试更新state=1,若成功表明未有线程获取锁,设置当前线程为owner,线程继续执行。若更新失败表示已有其他线程获取到锁,将当前线程包装为一个Node,并cas设置waitStatus为-1(Node.Singal)放入AQS队列尾部(若head为空,则新建一个Node节点作为head),设置prev和next。然后自旋对这个Node尝试获取锁,成功则将此Node设为head,前一个节点的next设为null帮助gc回收,失败则park当前线程使之阻塞。

unlock()

使state减1,若state为0表明锁已全部释放完。获取AQS结点中的头结点的下一节点,唤醒其中线程,则唤醒此时被park的线程继续自旋获取到锁。如果是共享模式则在自旋设置head之后多执行了一步操作,继续唤醒后续共享模式结点中的线程。

await()

必须在当前线程获取锁时才能执行,首先把当前线程构成一个Node,设置waitStatus为-2(Node.CONDITION)并放入ConditionObject队列尾部。然后对当前线程完全释放锁,唤醒AQS中的头部线程,随后park当前线程。

singal()&singalAll()

取ConditionObject队列首部节点,并把它从队列中移除,CAS将Node的waitStatus从CONDITION置为0,随后放入AQS队列的尾部,再设置waitStatus从CONDITION置为-1,unpark唤醒这个线程。

CAS操作

CAS比较交换是一种乐观锁机制,其过程是取当前值和预期值进行比较,若一致,则将更新值作为最新值,不一致则操作失败,它是一种cpu指令级别的原子操作,且是直接根据内存中的地址来做对比更新。

park&unpark

park&unpark底层原理是获取一个许可&给予一个许可,在jvm中每个线程有一个Parker实例,其中有个_counter变量来记录是否有许可。
1.unpark时先更新_counter为1,并判断之前的_counter小于1;
如果小于1,则去唤醒阻塞的线程,若有线程被唤醒然后使_counter为0;
如果给定线程没有启动start,则该操作没有任何效果.
2.park,则会检测_counter是否大于0;
如果大于0则将_counter变成0,线程继续执行,否则堵塞线程。
3.线程被park后阻塞时,如果被中断也会被唤醒。

JUC并发工具包

1.Semaphore 信号量是一类经典的同步工具。信号量通常用来限制线程可以同时访问的(物理或逻辑)资源数量。

2.CountDownLatch闭锁 一种非常简单、但很常用的同步辅助类。其作用是在完成一组正在其他线程中执行的操作之前,允许一个或多个线程一直阻塞。CountDownLatch闭锁状态包括一个计数器,该计数器被初始化为一个正数,表示需要等待的事件数量。countDown方法将递减计数器,表示有一个事件已经发生了,而await方法等待计数器到达零,这表示所有需要的事件都已经发生。如果计数器的值为非零,那么await会一直阻塞直到计数器为零,或者等待中的线程中断,或者等待超时。

3.CyclicBarrier栅栏类似于闭锁,它能阻塞线程直到某个事件发生。当线程到达栅栏位置时,将调用await方法,这个方法将阻塞直到所有线程都到达阻塞位置。如果所有线程都到达了栅栏的位置,那么栅栏将打开,此时所有线程都将被释放,而栅栏将被重置以便下次使用。如果对await的调用超时,或者await阻塞的线程被中断,那么栅栏就被认为是打破了,所有阻塞的await调用都将终止并抛出BrokenBarrierException。如果成功地通过栅栏,那么await将为每个线程返回一个唯一的到达索引号,我们可以利用这些索引来“选举”产生一个领导线程,并在下一次迭代中由该领导线程执行一些特殊的工作。
栅栏与闭锁的关键区别在于:所有线程必须同时到达栅栏位置,才能继续执行。而且闭锁只能使用一次,而栅栏可以重复循环使用。

4.JDK1.7中的Phaser一种可重用的同步屏障,功能上类似于CyclicBarrier和CountDownLatch,但使用上更为灵活。CountDownLatch和CyclicBarrier都是只适用于固定数量的参与者,Phaser适用于可变数目的屏障。

5.JDK1.8中的StampedLock,优化了之前的读写锁ReentrantReadWriteLock。读写锁特点是读-读不互斥(Node设置为共享模式),读-写互斥,写-写互斥,本质上来说都是悲观锁。StampedLock在将读锁优化成了一种乐观锁机制,而对于读-写的情况,在读的时候会判断是否有写操作,有则再读一次。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,294评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,493评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,790评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,595评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,718评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,906评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,053评论 3 410
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,797评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,250评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,570评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,711评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,388评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,018评论 3 316
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,796评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,023评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,461评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,595评论 2 350

推荐阅读更多精彩内容