atitit.
1.、全手工，
把责任交给程序员，C最盛行的年代就是这么做的。但是这样做的问题也很明显，由此产生的程序Bug不计其数。
2.引用计数，
这种做法的中心思想是通过“引用关系”确定对象的生存期，
作者
转载请注明来源：
2.1.成本也显而易见，
首先你至少得给每个对象准备一个引用计数器，对于大量的小对象，这可能是一个无法接受的成本；
2.2.循环引用的问题，
为此你得引入weakpointer或者blockpointer，前者是弱引用关系，允许悬空引用存在，后者是显式的对象池生存期管理，在能确定的时候一揽子销毁一堆相互引用的对象，跳过循环引用的检测。
实时释放死对象，但却无法处理存在循环引用的对象图的释放。这个问题一定程度上可以通过引入弱引用的概念来解决
纯洁的这个方式·引用计数法不能解决循环引用问题
2.3.引用计数方式其实也有经典的卡顿情况
。例子之一就是一个对象个数很多、引用链很长的对象图假如只是被一个引用而留活，那么那个引用一死就会引发大量对象扎堆释放（但却不是“批量释放”，开销不同），这一样会引起卡顿。
3.MarkandSweepGC，也就是Java所采用的方式。
这种方式的好处是你不需要给每个对象准备一个引用计数器，而且可以集中销毁大量的小对象，提高内存利用率，，但代价就是销毁对象确定性丧失，而且你总是需要大量额外的内存（至少1到2倍）来容纳尚未来得及销毁的对象，这样才能保证垃圾收集器不会频繁启动影响程序的执行效率。目前看来，资源分配和回收的问题没有什么完美的解决方案，如果程序是运行在资源严格受限的场合，手工管理可能是唯一可行的选择；如果是对于响应性要求很严格的场合，引用计数可能更为合适；如果是典型的服务器端程序，GC是综合成本最低的。
4.timer
建立这个资源的时候儿不个
5.ARM自动资源管理
Java7build105版本开始，Java7的编译器和运行环境支持新的try-with-resources语句，称为ARM块(AutomaticResourceManagement)，自动资源管理。
6.注解增强
publicstaticvoidcustomBufferStreamCopy(String[]args)throwsException{
@CleanupInputStreamin=newFileInputStream(args[0]);
@CleanupOutputStreamout=newFileOutputStream(args[1]);
byte[]buf=newbyte[8192];
inti;
while((i=in.read(buf))!=-1){
out.write(buf,0,i);
}
}
一个代码生成器感觉也不错
7.常用语言的处理方式
，但通用的能处理带循环引用对象图的引用计数都是有别的管理方式备份的（通常是某种tracingGC，例如mark-sweep；也有名为“trial-deletion”的循环检测方法，但这个通常比tracing性能更差所以用得较少），例如CPython使用以引用计数为主、mark-sweep为辅的方式，AdobeFlash的ActionScriptVM2（AVM2）也是以延迟引用计数（DRC）为主、增量/保守式mark-sweep为辅
8.问题：：为什么不做资源的自动管理
跟个内内存雅十
引用
(1封私信_1条消息)Java等语言的GC为什么不实时释放内存？-知乎.htm
在旅途中，我遇见了你，你我相识是缘分！看着你手中的戒指，
