@leonard916 版本不是你想升 想升就能升

@ppyybb 哦哦,原来是这样,两年前的内容都还记得也是很厉害了,我是因为疫情原因,在家没事干,学习下 AQS,发现这里可能会有点问题就提出来大家一起讨论一下,也感谢大家跟我一起讨论,祝大家身体健康,工作顺利

@ppyybb 在每次 submit 的时候睡一下是不科学的一是因为时间原因,每个线程都睡太耗时间了;二是因为这样也不能确保所有线程同时 take,睡了的话上一个线程反而会执行到 await 把锁释放了

在每次 submit 的时候睡一下是不科学的一是因为时间原因,每个线程都睡太耗时间了;二是因为这样也不能确保所有线程同时 take,睡了的话上一个线程反而会执行到 await 把锁释放了

@ppyybb 我说的就是主线程 poll 之前 sleep 一下,确保上边的线程执行完毕全部进入阻塞状态,如果上边的线程全部都在 await 的话入 sync 队列的 node 数量就是 0 了呀,这样就不会有延迟
我是说这样不会有问题
你应该想说的为了证明这个问题 应该在每次 submit 的时候睡一下确保上一个线程在执行 takeLock.lockInterruptibly()?

@ppyybb 我试过的,直接主线程睡会儿再执行 poll(1000, TimeUnit.MILLISECONDS)就好了,只要 AQS 队列里没有排队的 node 这个方法还是很及时的,主要就是看是否有大量线程在抢锁,如果有,那么 poll(1000, TimeUnit.MILLISECONDS)就可能超过指定时间返回,awaitNanos(nanos)相比 await 只是多了一个自我唤醒的步骤,唤醒之后还是得抢锁,但是由于非公平锁的原因确实不好测试,有可能两次抢锁都一下就抢到了而不仅 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 唤醒下个线程,这样时间就有可能会长

淦 为啥我的图不显示

xxx


@mreasonyang
@ppyybb
@lu5je0
@optional
大致代码如上 理论上线程数量越多 AQS 里的链表越长,时间越长,但是正如 @lu5je0 所说的,AQS 默认实现为非公平锁,有可能一来就直接拿到锁而不进 AQS 链表,所以结果为 1s,但是如果他进了 AQS 链表就会产生误差,我电脑只能跑到 10w 线程 如图所示

ExecutorService get = Executors.newCachedThreadPool();
LinkedBlockingQueue linkedBlockingQueue = new LinkedBlockingQueue();
for (int i = 0; i < 100000; i++) {
get.submit(() -> {
try {
System.out.println("成功获取"+linkedBlockingQueue.take());
Thread.sleep(10000);
} catch (InterruptedException e) {
e.printStackTrace();
}
});
}
get.submit(() -> {
long l = System.currentTimeMillis();
Object poll = null;
try {
poll = linkedBlockingQueue.poll(1000, TimeUnit.MILLISECONDS);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(poll);
System.out.println( System.currentTimeMillis()-l);

});

@mreasonyang
@ppyybb
@lu5je0
@optional

@optional 可能也有点关系吧

@ppyybb 但是极端情况下:比如有多个线程在 poll,他们都加入了 AQS 等待队列,这个时候 awaitNanos 超时时间到了再把 awaitNanos 这个线程从 Condition 里的链表转移到 AQS 里的链表,由于先进先出原则.调用 awaitNanos 的这个线程得等到 AQS 之前的所有 Node 都出队之后才会到他去抢锁,所以这个值也可能很大甚至误差几秒钟都可能

摸

我 touchbar 黑了一部分 已经找售后了

@evam 哈哈哈哈哈哈哈 🐂🍺

@Smilencer 严谨!