moooonk commented on PR #2092: URL: https://github.com/apache/fury/pull/2092#issuecomment-2721476026
> @moooonk 当核心线程数不够时，调用addFury会把变量activeCacheNumber加上去，后面没有减回来，会导致当这个线程被回收后，后面核心线程数不够就走不到addFury逻辑，只能阻塞等其他线程释放了 我反复确认了应该没有这个问题，我来解释一下这个修改的核心思路 1.activeCacheNumber这个变量的含义已经从当前可用的Fury对象数量改成了“构造令牌”这个概念，所谓构造令牌，既成功自增此字段且自增后不超过最大值限制的线程可以初始化新的Fury对象。此改动的用意是，在控制对象池的最大容量的同时，使得哪个线程会构造Fury对象变为一个确定性的行为，而构造过程会修改factoryCallback和allFury两个变量，所以将lock缩小到真正的构造过程中 2.lock缩小到只和其他需要构造新的Fury对象的线程互斥，拿取和归还过程不再共享lock，因为其实在不参与构造过程的线程视角，构造新的Fury对象对他们没有任何意义，他们只关心空闲队列里是否有可供使用的对象，如果activeCacheNumber已经增加到最大值，而且空闲队列没有可供使用的对象时直接进入阻塞等待即可，无需全程加锁 3.旧版实现选择将新构造的Fury对象直接放回空闲队列供所有线程重新竞争，可能会导致构造线程本身竞争失败，而重新进入等待状态，这个看似公平的设计并无意义，所以新版实现中改为，新构造的Fury对象直接返回给构造线程使用，待其用完归还后自然会被其他线程共享，以减少简化整个竞争流程，去掉难以理解的自旋等待代码逻辑 4.旧版实现选择了一旦扩容就不会再缩容的逻辑，对象池的释放方式只有整体闲置超过时间后整体释放，我觉得作为一个内存对象，而非网络连接类型的对象，此设计可以接受，故不做优化 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
