- 论坛徽章:
- 0
|
终于看到了finalize使用的副作用了....
由于GC调用finalize的过程间隔时间比较的长,如果程序在短的时间间隔之内大量构造生命期很短的某个对象(比如Graphics), 当GC进行回收的时候,会造成大量finalize的涌塞. 因为J2ME只支持native interface的 finalize 函数, 而 native 函数调用的成本比 java 方法大很多(需要拷贝栈), 就会造成用户明显能够感受到的停顿.
但是由于其他原因, 对象没有办法接受用户Midlet发来的主动释放请求, 那么除了添加 finalize 就只能在VM调度切换 Midlet 的时候进行释放了. 而后一种实现方式可能会使 VM 需要的内存峰值大大增加....
解决方法: --- 使用 Proxy 对象
Proxy --- 处理一般的不涉及 finalize 相关数据的操作, 外部接口, 不含有 finalize 方法, 含有 KernelImpl 对象实例
KernelImpl --- 含有 finalize 方法 和 所有涉及需要被 finalize 的处理的相关变量的使用的函数.
这种模式可以通过尽量孤立 finalize 的数据和操作集合的方式来缓解 finalize 可能造成的影响. 比如 3D 接口可能需要 finalize 而 2D 接口不需要的话, 就可以用这种方式来扩展, 来保证纯 2D 程序的性能表现.
总结出来一点, 为什么 Java 程序那么看重设计模式, 因为 Java 的封装体系和透明性造成的某些执行行为不可控, overhead 以及 perceivable delay 一定程度上必须依靠设计模式去弥补...
[color="#0079a2"]Trackback地址:
[color="#0079a2"]http://www.yculblog.com/trackback/4/886815
本文来自ChinaUnix博客,如果查看原文请点:http://blog.chinaunix.net/u/11783/showart_58481.html |
|