既然你知道“每一次访问open一次，然后访问完把数据读回来马上close”或者“pool”机制，那么你就是知道db连接的生命期的，如果你不知道，如何设计这些？或者说如果你不是使用别人封装好的东西，那么你仍然不得不知道……

pool和gc是很不同的……因为gc是独立线程，而且你无法修改它的代码来适应需求变化……但是pool如果作为一个模块，那么是可以合并到上层应用的线程中的，这样对于pool中的资源的分配和释放，其行为限制会小一些，因为你可以避开线程问题。而且作为一个模块，pool最终是可控的——你可以了解其背后的行为，你可以在其代码的层面来修改和定制。而且pool本身也可以放在栈中，可以说其与栈机制是不矛盾的……pool中也可以有pool，可以实现层级管理……
“缩小的时机不确定”对于非独立线程pool应该很难实现……因为对于非独立线程pool，只需要单步跟踪就能知道在什么情况下会缩小，除非你没有它的源码……但是哪怕自己写个pool都可以，相对来说这比gc容易写，而且不像gc那样对语言特性那么挑剔……关键是，这个时机对于pool是确定的，因为pool会在确定的条件下才能获得CPU的使用权（即上层调用其成员函数的时候），而其缩小的条件也是确定的——否则它如何工作？无论如何，程序员对pool的控制力都比gc强得多……
如果说它在你看来和gc没区别，那只能说你只是使用这些组件，而不是自己开发这些组件……从我的角度来看，只能使用别人做好的组件是缺乏安全感的，因为总有一些问题需要自己开发基础组件……

所谓“希望的只是用那些资源，我不是很想去关心它的生命周期”，恐怕只有那些用脚本写游戏逻辑的策划可以这么安逸，大多数时候程序员多多少少都有维护实现层面细节的责任，特别是那些负责底层模块或者库开发的人。

我说的那3点的内容是资源管理机制应该符合什么样的标准……如果你使用现成的封装而不需要自己管理资源，自然不需要关心这个……