atitit.资源释放机制--attilax总结

atitit.资源释放机制--attilax总结

1. 、全手工， 1

2. 引用计数， 1

2.1. 成本也显而易见。 1

2.2. 循环引用的问题， 2

2.3. 引用计数方式事实上也有经典的卡顿情况 2

3. Mark and Sweep GC，也就是Java所採用的方式。 2

4. timer 超时机制attilax 建立 2

5. ARM自己主动资源管理 3

6. 注解增强 3

7. 经常使用语言的处理方式 3

8. 问题：：为什么不做资源的自己主动管理 3

1. 、全手工，

把责任交给程序猿，C最盛行的年代就是这么做的。可是这样做的问题也非常明显，由此产生的程序Bug不计其数。

2. 引用计数，

这样的做法的中心思想是通过“引用关系”确定对象的生存期，

作者:: 老哇的爪子 Attilax 艾龙，  EMAIL:1466519819@qq.com

转载请注明来源： http://blog.csdn.net/attilax

2.1. 成本也显而易见。

首先你至少得给每一个对象准备一个引用计数器。对于大量的小对象，这可 能是一个无法接受的成本；

2.2. 循环引用的问题。

为此你得引入weak pointer或者block pointer，前者是弱引用关系。同意悬空引用存在，后者是显式的对象池生存期管理。在能确定的时候一揽子销毁一堆相互引用的对象，跳过循环引用的检 測。

实时释放死对象，但却无法处理存在循环引用的对象图的释放。这个问题一定程度上能够通过引入弱引用的概念来解决

清纯的这个方式·  引用计数法不能解决循环引用问题

2.3. 引用计数方式事实上也有经典的卡顿情况

。样例之中的一个就是一个对象个数非常多、引用链非常长的对象图假如仅仅是被一个引用而留活，那么那个引用一死就会引发大量对象扎堆释放（但却不是“批量释放”，开销不同）。这一样会引起卡顿。

3. Mark and Sweep GC，也就是Java所採用的方式。

这样的方式的优点是你不须要给每一个对象准备一个引用计数器，并且能够集中销毁大量的小对象，提高内存利用率。但代价就是 销毁对象确定性丧失。并且你总是须要大量额外的内存（至少1到2倍）来容纳尚未来得及销毁的对象，这样才干保证垃圾收集器不会频繁启动影响程序的运行效 率。

眼下看来。资源分配和回收的问题没有什么完美的解决方式，假设程序是执行在资源严格受限的场合。手工管理可能是唯一可行的选择。假设是对于响应性要求非常严格的场合。引用计数可能更为合适。假设是典型的server端程序。GC是综合成本最低的。

4. timer 超时机制attilax 建立

建立这个资源的时候儿不个timer建立,超时释放...

5. ARM自己主动资源管理

Java 7 build 105 版本号開始，Java 7 的编译器和执行环境支持新的 try-with-resources 语句，称为 ARM 块(Automatic Resource Management) ，自己主动资源管理。

6. 注解增强

public static void customBufferStreamCopy(String[] args) throws Exception{

@Cleanup InputStream in = new FileInputStream(args[0]);

@Cleanup OutputStream out = new FileOutputStream(args[1]);

byte[] buf = new byte[8192];

int i;

while ((i = in.read(buf)) != -1) {

out.write(buf, 0, i);

}

}

一个代码生成器感觉也不错

7. 经常使用语言的处理方式

，但通用的能处理带循环引用对象图的引用计数都是有别的管理方式备份的（一般是某种tracing GC，比如mark-sweep。也有名为“trial-deletion”的循环检測方法，但这个通常比tracing性能更差所以用得较少），比如 CPython使用以引用计数为主、mark-sweep为辅的方式，Adobe Flash的ActionScript VM 2（AVM2）也是以延迟引用计数（DRC）为主、增量/保守式mark-sweep为辅

8. 问题：：为什么不做资源的自己主动管理

跟个内内存雅十,能做auto mana了啊..

引用

(1 封私信 _ 1 条消息) Java 等语言的 GC 为什么不实时释放内存？ - 知乎.htm