引用:
|
作者: sjinny pool和gc是很不同的……因为gc是独立线程，而且你无法修改它的代码来适应需求变化……但是pool如果作为一个模块，那么是可以合并到上层应用的线程中的，这样对于pool中的资源的分配和释放，其行为限制会小一些，因为你可以避开线程问题。而且作为一个模块，pool最终是可控的——你可以了解其背后的行为，你可以在其代码的层面来修改和定制。而且pool本身也可以放在栈中，可以说其与栈机制是不矛盾的……pool中也可以有pool，可以实现层级管理…… |
pool里面的实现我不清楚，他可能是独立线程监控缩小，可能是每次释放的时候check一下是否需要缩小。这一部分是可以单独优化和配置的。另外，这个pool我没有源代码，是整个framework (ADO.NET)的一部分。我最初也不知道这个pool的存在，只是觉得这么频繁地open/close connection会不会太慢。后来发现多虑了。
另外，这种需求也很难变化，至少对于那个pool我们的需求没有变化过。它也可以进行一定的配置，但默认的还不错所以我们也没有改过。GC也有一些类似的接口可以configure.
pool可以不可以在stack上也是取决于pool的design, 没有必要的feature只会让使用变得复杂。比如上面的ADO.NET的connection pool直接可以这么用：
代码:
using (SqlConnection conn = new SqlConnection(myConnectionString))
{
conn.Open();
doSomething(conn);
}
哪里都看不到那个pool. 但是他其实存在着。它就没有想要让别人介入它的生命周期。这也使得它非常好用。
引用:
|
作者: sjinny 我说的那3点的内容是资源管理机制应该符合什么样的标准……如果你使用现成的封装而不需要自己管理资源，自然不需要关心这个…… |
不，这个封装未必是现成的，我自己来做恐怕最终成果也就是那样。不会被局限在你那个“确定性”里面，因为它没有带来好处反而局限了抽象。