首页   注册   登录
 yangyuhan12138 最近的时间轴更新
yangyuhan12138

yangyuhan12138

V2EX 第 306391 号会员,加入于 2018-04-06 14:30:50 +08:00
了解 AQS 的进来讨论一下
Java  •  yangyuhan12138  •  12 天前  •  最后回复来自 yangyuhan12138
23
与人面对面交流时眼睛到底应该看哪里
生活  •  yangyuhan12138  •  43 天前  •  最后回复来自 brace
67
R1 屏幕出问题了
锤子手机  •  yangyuhan12138  •  161 天前  •  最后回复来自 yangyuhan12138
10
有没有喜欢黑莓的 v2er
  •  2   
    Android  •  yangyuhan12138  •  2018-10-16 11:56:19 AM  •  最后回复来自 BingoXuan
    32
    迫于 2018 版 mac,忍痛出自用 17 乞丐版 mac
  •  2   
    二手交易  •  yangyuhan12138  •  2018-08-14 22:31:32 PM  •  最后回复来自 zizou10
    9
    出 CherryG80-3494LYCUS-0
    二手交易  •  yangyuhan12138  •  2018-04-11 22:28:44 PM  •  最后回复来自 yangyuhan12138
    2
    yangyuhan12138 最近回复了
    12 天前
    回复了 yangyuhan12138 创建的主题 Java 了解 AQS 的进来讨论一下
    @ppyybb 哦哦,原来是这样,两年前的内容都还记得也是很厉害了,我是因为疫情原因,在家没事干,学习下 AQS,发现这里可能会有点问题就提出来大家一起讨论一下,也感谢大家跟我一起讨论,祝大家身体健康,工作顺利
    12 天前
    回复了 yangyuhan12138 创建的主题 Java 了解 AQS 的进来讨论一下
    @ppyybb 在每次 submit 的时候睡一下是不科学的一是因为时间原因,每个线程都睡太耗时间了;二是因为这样也不能确保所有线程同时 take,睡了的话上一个线程反而会执行到 await 把锁释放了
    12 天前
    回复了 yangyuhan12138 创建的主题 Java 了解 AQS 的进来讨论一下
    在每次 submit 的时候睡一下是不科学的一是因为时间原因,每个线程都睡太耗时间了;二是因为这样也不能确保所有线程同时 take,睡了的话上一个线程反而会执行到 await 把锁释放了
    12 天前
    回复了 yangyuhan12138 创建的主题 Java 了解 AQS 的进来讨论一下
    @ppyybb 我说的就是主线程 poll 之前 sleep 一下,确保上边的线程执行完毕全部进入阻塞状态,如果上边的线程全部都在 await 的话入 sync 队列的 node 数量就是 0 了呀,这样就不会有延迟
    我是说这样不会有问题
    你应该想说的为了证明这个问题 应该在每次 submit 的时候睡一下确保上一个线程在执行 takeLock.lockInterruptibly()?
    12 天前
    回复了 yangyuhan12138 创建的主题 Java 了解 AQS 的进来讨论一下
    @ppyybb 我试过的,直接主线程睡会儿再执行 poll(1000, TimeUnit.MILLISECONDS)就好了,只要 AQS 队列里没有排队的 node 这个方法还是很及时的,主要就是看是否有大量线程在抢锁,如果有,那么 poll(1000, TimeUnit.MILLISECONDS)就可能超过指定时间返回,awaitNanos(nanos)相比 await 只是多了一个自我唤醒的步骤,唤醒之后还是得抢锁,但是由于非公平锁的原因确实不好测试,有可能两次抢锁都一下就抢到了而不仅 AQS 队列
    12 天前
    回复了 yangyuhan12138 创建的主题 Java 了解 AQS 的进来讨论一下
    @ppyybb
    1.线程是同步创建的,循环完了线程应该就创建完了,不存在等待线程创建地说法
    2.take 方法执行到 notEmpty.await()的时候 这些 node 确实会 condition 队列里,但是 take 方法一进来就有 takeLock.lockInterruptibly()抢锁的操作,理想状态 100000 个线程同时抢锁只有一个抢到其余的应该进 AQS 队列(事实上并没有这么多线程进入队列,因为非公平锁和线程并不是同时启动的原因)
    3.此时主线程调用 poll(1000, TimeUnit.MILLISECONDS)方法,这个方法会抢两次锁第一次为 takeLock.lockInterruptibly(),第一次抢锁的时间并没有计入等待时间,然后执行 notEmpty.awaitNanos(nanos),挂起当前线程,等待传入时间结束之后唤醒当前线程,并将当前 node 移入 AQS 队列,再次抢锁,由于两次抢锁都是非公平的所以都有可能一来就抢到,而不进 AQS 队列,理想状态为两次都进入队列,然后等待其他线程挨个 unlock 唤醒下个线程,这样时间就有可能会长
    13 天前
    回复了 yangyuhan12138 创建的主题 Java 了解 AQS 的进来讨论一下
    淦 为啥我的图不显示
    xxx
    13 天前
    回复了 yangyuhan12138 创建的主题 Java 了解 AQS 的进来讨论一下
    13 天前
    回复了 yangyuhan12138 创建的主题 Java 了解 AQS 的进来讨论一下
    @mreasonyang
    @ppyybb
    @lu5je0
    @optional
    大致代码如上 理论上线程数量越多 AQS 里的链表越长,时间越长,但是正如 @lu5je0 所说的,AQS 默认实现为非公平锁,有可能一来就直接拿到锁而不进 AQS 链表,所以结果为 1s,但是如果他进了 AQS 链表就会产生误差,我电脑只能跑到 10w 线程 如图所示
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3639 人在线   最高记录 5168   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 04:25 · PVG 12:25 · LAX 20:25 · JFK 23:25
    ♥ Do have faith in what you're doing.