
Activity
lkqm commentedon May 31, 2020
目前确实会存在这样的问题, 后续使用
lock.tryLock修复这个问题Fix binarywang#1582 use lock.tryLock() avoid waiting for locks for a …
🐛 #1582 use lock.tryLock() to avoid waiting for locks for a long time
binarywang commentedon Jul 19, 2020
已修复
cookier commentedon Sep 16, 2020
请问一下把
lock改成tryLock有什么提升吗?因为我看这里
tryLock也是通过不断循环,判断是否锁住,跟lock直接锁住好像效果一样?lkqm commentedon Sep 16, 2020
如果用lock这里有上万个请求会导致最后一个请求会等待前面9999个人的时间。而实际上只希望请求tencent获取accessToen只有一个线程,而使用tryLock会在某个线程更新accessToken后,其余线程只需要短暂等待后即可获取有效的accessToekn.
cookier commentedon Sep 17, 2020
在做测试之前,看你的说明后我理解是
lock为单纯阻塞,并发线程都在干等着;tryLock则保持了并发线程的灵活性,只需要短暂等待就能拿到结果。不过再仔细想,每个线程都要额外等多100毫秒,响应不是更慢吗?模拟并发测试后发现
lock方式执行时间1000+。tryLock执行时间3000+,不知道我测试方式是否正确。