这样A处理起来稍微有点麻烦。因为A需要不断读回传的通道。不过这样也有好处，就是不需要锁。

我说那种B释放的方式表面看起来简单，但是pool内部需要锁控制。我觉着确实可以试试。

你说这种回传的方式有实际情况用到过么？有什么坑没有？

【 在 AlphaO 的大作中提到: 】
: 第一个通道方式似乎已经相当于丢回池子了
: :
--
FROM 114.254.2.*

是的，我也觉得pool里面的锁可能慢。

就是A得不断地读这个回传的通道把B释放发回来的obj读出来... 我说那种poll方式只需要发给B东西，不需要读B发回来的东西
【 在 AlphaO 的大作中提到: 】
: 我觉得pool实现不会比channel更快。
: “A需要不断读回传的通道”是什么意思？很让人费解
:
--
FROM 114.254.2.*

b并不能持续使用obj。obj中的内容是a填充的。需要返回给a，这样a才能重复利用，再次填充。如果b反复理由obj，那就是单线程了。

我说的多线程场景是：
A ：有个内存池。收到外部事件。从池中取出obj，根据事件初始化obj。把obj通过通道发给B。

B：收到obj。处理。释放obj到obj所属的池中。

所以，如果通过通道释放obj，那A就得读取释放通道。读出来一个obj后放回到池中。
【 在 AlphaO 的大作中提到: 】
: 这不是个问题，b用buffer，那么b用完，发回给b即可。没a什么事
--
修改:chunhui FROM 221.216.116.*
FROM 221.216.116.*

要这样那就是单线程的池了。这个简单。已有办法。

多线程情况：
用buff的是b。但buff的内容得a填充。否则就不用a b俩线程了。

【 在 AlphaO 的大作中提到: 】
: 用buffer的是b，等buffer的也是b，你这里的a多余了，没起什么作用，b一直重用这n个buffer
--
FROM 221.216.116.*

对。就是这个过程。
可能用队列回传buff确实比常规的内存池好。我前面说的就是，这样的话，A需要不断地读取回传的通道，来拿B释放回来的，空buff。有点麻烦。

如果这些buff，不再需要给其他线程的话，仅限于A B来回传。这个麻烦可以接受。如果还有其他的需要。就更麻烦了，得想其他办法。

我打算先用这个办法试试。
【 在 AlphaO 的大作中提到: 】
: 哦，明白了，a、b都等着buffer用，a先用，b后用。
: 在a、b线程之前，初始创建n个buffer，然后给a
: a等buffer，每拿到1个buffer，填充给b
: ...................
--
FROM 117.133.52.*