自适应收集器

在第一篇：有关于 JVM 的垃圾收集(一)  中谈到过几种垃圾收集的算法，然而我们的 JVM 启动之后并不要求彻头彻尾的死板的使用一种垃圾收集算法，固定的算法参数。因为某种情况下某些垃圾收集算法工作得更好，而别外一些收集算法在另外的情况下工作得更好，所以自适应的垃圾收集技术应运而生。自适应算法监视堆中的情形，并且对应的调整为合适的垃圾收集技术。或能是换一种垃圾收集算法，或者是调整当前算法参数，或者把堆划分为子堆，同时在不同的子堆中使用不同的算法。

简述火车算法

垃圾收集一般都会停止整个程序的运行来查找和收集垃圾对象，它们可能在程序执行的任意时刻暂停，并且暂停的时间也无法确定。垃圾收集也可能使得程序对事件响应迟钝，无法满足实时系统的要求。如果一种垃圾收集算法可能导致用户可察觉的到的停顿或者使得程序无法适合实时系统的要求，这种算法被称作破坏性。垃圾收集算法的还有一个基本目标是使本质上的破坏性尽可能少，如果可能的话，尽可能消除这种破坏性。 Read More

应用服务器一般都支持热部署(Hot Deployment)，更新代码时把新编译的确类替换旧的就行，后面的程序就执行新类中的代码。这也是由各种应用服务器的独有的类加载器层次实现的。那如何在我们的程序中也实现这种热加载功能呢？即要在虚拟机不关闭的情况下(比如一个)，换个类，JVM 就知道加载这个新类，执行新类中的逻辑呢？下面就简单演示这样一个热加载的例子，首先大致了解一下类加载器。

标准 Java 启动器的类加载器层次

1. 引导类加载器(bootstrap):   加载内核 API，如 rt.jar(java.lang、java.io 等)

2. 扩展类加载器(extension):   加载的默认扩展来自于 jre/lib/ext

3. 系统类加载器(system):       类路径上的类，如 com.unmi.*

说明：这只是标准 Java 启动器运行程序时的类加载器层次，像应用服务器中的类加载器通常会多一两层，也是在这个基础上的延伸。上面的类加载层次存在自上而下的委托关系，委托加载不在这里细讲。 Read More

Java 中使用 new、newarray、anewarray 和 multianewarray 指令来创建的对象，当这些对象不再使用时由垃圾收集来释放。 那么 反序列化等都是间接使用了前面的某个指令, clone()  是个本地方法？

JVM 规范不需要任何特定的垃圾收集技术，甚至也没要求有垃圾收集机制。 大概只是说不需要手工释放内存，具体怎么实现各 JVM 自行决定。

GC 除了释放不再被引用的对象，还要处理堆碎片， 整理出连续的空闲空间才能放得下新的对象。不至于出现总的空闲空间足够，但碎片太多而报出 "Out of Memory" 的异常。

GC 有两个好处： 一个是提高了生产率，不用埋头于 Memory Link 的有时甚至是逐行的检查；二，GC 也是 Java 安全策略的一部分，有了它不至于因错误的释放内存而导至 JVM 崩溃。 但是 GC 的一个潜在缺陷影响了程序的性能，它需要一直在后台不时的做些事情，而且实时性也有所欠缺。 Read More

之前整一星期忙得不可开交，关于技术已无暇顾及，这个星期总算有朝向正常化的迹象了。回到网络上多紧跟着技术变化的步伐，拣自认为好的东西摘记下来。

原文：http://www.infoq.com/cn/news/2008/02/JSPWeaver10

社区 Java

主题 动态语言, 企业架构