自适应收集器
在第一篇：有关于 JVM 的垃圾收集(一) 中谈到过几种垃圾收集的算法，然而我们的 JVM 启动之后并不要求彻头彻尾的死板的使用一种垃圾收集算法，固定的算法参数。因为某种情况下某些垃圾收集算法工作得更好，而别外一些收集算法在另外的情况下工作得更好，所以自适应的垃圾收集技术应运而生。自适应算法监视堆中的情形，并且对应的调整为合适的垃圾收集技术。或能是换一种垃圾收集算法，或者是调整当前算法参数，或者把堆划分为子堆，同时在不同的子堆中使用不同的算法。
简述火车算法
垃圾收集一般都会停止整个程序的运行来查找和收集垃圾对象，它们可能在程序执行的任意时刻暂停，并且暂停的时间也无法确定。垃圾收集也可能使得程序对事件响应迟钝，无法满足实时系统的要求。如果一种垃圾收集算法可能导致用户可察觉的到的停顿或者使得程序无法适合实时系统的要求，这种算法被称作破坏性。垃圾收集算法的还有一个基本目标是使本质上的破坏性尽可能少，如果可能的话，尽可能消除这种破坏性。 阅读全文 >>
应用服务器一般都支持热部署(Hot Deployment)，更新代码时把新编译的确类替换旧的就行，后面的程序就执行新类中的代码。这也是由各种应用服务器的独有的类加载器层次实现的。那如何在我们的程序中也实现这种热加载功能呢？即要在虚拟机不关闭的情况下(比如一个)，换个类，JVM 就知道加载这个新类，执行新类中的逻辑呢？下面就简单演示这样一个热加载的例子，首先大致了解一下类加载器。
标准 Java 启动器的类加载器层次
1. 引导类加载器(bootstrap): 加载内核 API，如 rt.jar(java.lang、java.io 等)
2. 扩展类加载器(extension): 加载的默认扩展来自于 jre/lib/ext
3. 系统类加载器(system): 类路径上的类，如 com.unmi.*
说明：这只是标准 Java 启动器运行程序时的类加载器层次，像应用服务器中的类加载器通常会多一两层，也是在这个基础上的延伸。上面的类加载层次存在自上而下的委托关系，委托加载不在这里细讲。 阅读全文 >>
Java 中使用 new、newarray、anewarray 和 multianewarray 指令来创建的对象，当这些对象不再使用时由垃圾收集来释放。那么 反序列化等都是间接使用了前面的某个指令, clone() 是个本地方法？
JVM 规范不需要任何特定的垃圾收集技术，甚至也没要求有垃圾收集机制。大概只是说不需要手工释放内存，具体怎么实现各 JVM 自行决定。
GC 除了释放不再被引用的对象，还要处理堆碎片，整理出连续的空闲空间才能放得下新的对象。不至于出现总的空闲空间足够，但碎片太多而报出 "Out of Memory" 的异常。
GC 有两个好处：一个是提高了生产率，不用埋头于 Memory Link 的有时甚至是逐行的检查；二，GC 也是 Java 安全策略的一部分，有了它不至于因错误的释放内存而导至 JVM 崩溃。但是 GC 的一个潜在缺陷影响了程序的性能，它需要一直在后台不时的做些事情，而且实时性也有所欠缺。 阅读全文 >>
看到 Maven 不断的演进, 著名的 Appfuse 也摒弃了 Ant 而采用了 Maven 作为它的构建管理工具，各个 Java IDE 对于 Maven 的支持也是纷纷上马，所以急迫的感觉对于 Maven 的出现是不容忽视了。Ant 纵然是能满足于我们的需求，不过 Ant 的 build.xml 脚本总那么臃肿不堪，不利于阅读。
而 Maven 与 Ant 同出一族，为 Apache 门下的师兄弟。既然 Apache 会再发明这样一个新轮子，相比于 Ant 确有它的许多独到之处。Maven 依赖了 ant-x.x.x 包，但要说是建立在 Maven 之上的话恐有不太合适。
关于 Maven 与 Ant 之间比较的文章在网上能找到不少，如 maven和ant的比较。具体的不细说，略表几个 Maven 关键之处：1. 对依赖包的处理十分优雅；2. 有大量可用的插件支持；3. 便于与其他工具的支持；4. 适合于多项目的开发。本人也是接触不久，还有许多有待发掘。 阅读全文 >>
现在早已是 Maven 2 了，可还是有机会用了一下 Maven 1，所用的版本是 Maven 1.0.2，刚开始尝试的时候出现以下两个问题：
1. 执行 maven genapp 时产生如下异常：
???????? commons-jelly-tags-interaction-20030211.143817.jar????
Error retrieving artifact from [http://www.ibiblio.org/maven/commons-jelly/jars/commons-jelly-tags-interaction-20030211.143817.jar]: java.net.ConnectException: Connection timed out: connect
?????? commons-jelly-tags-interaction-20030211.143817.jar ?????§°???
???????????????±???????¨??????????
commons-jelly-tags-interaction-20030211.143817.jar 阅读全文 >>
92. 在《Spring in Action》第一版 274 页说 DispatcherServlet 使用缺省 ControllerHandlerAdapter 时只会把控制权分发给 Controller 接口类型的类，而要配置 ThrowawayControllerHandlerAdapter 后，Dispatcherservlet 就把控制权分发给 ThrowawayController，配置如下： 阅读全文 >>
Spring MVC 中 Controller 的层次实在是多，有些眼花缭乱了。在单个的基础上，再新加两三个叫做丰富，再多就未必是好事，反而会令人缩手新闻片脚，无从定夺。多数 Controller 都是只完成一个任务，不过也有一个像 Struts 的 DispatchAction 的那样的 Conntroller，org.springframework.web.servlet.mvc.multiaction.MultiActionController，意即在一个 Controller 中处理多个动作，如同一个业务的增、删、改可以放在一起了。不至于增、删、改各自为政，造成代码混乱、重复难以维护。
本文中的 web.xml 的 org.springframework.web.servlet.DispatcherServlet 所处理的 url-pattern 是 *.html，如何搭建 Spring MVC 项目不细加说明，可参考我前面同系列的文章。
例如，下面的 UserController，有两个签名一样的 updateUser() 和 deleteUser() 方法 阅读全文 >>
本篇讲述在 XML 中使用了 DTD 的情况下，用 JDOM 解析时如何加速，使用 Schema 验证 XML 的不在讨论之中。所用的是一个 Struts 1.3 的配置文件，大小为 102 K。
我们用 JDOM 解析 XML 最简单的代码莫过于以下两行代码，不过为了测试我们在其前后加上记录执行时间的代码：
|
1 2 3 4 |
long start = System.currentTimeMillis(); SAXBuilder builder = new SAXBuilder(); Document document = builder.build("struts-config.xml"); System.out.println("耗时：" + (System.currentTimeMillis()-start)+" 毫秒."); |
在这个 struts-config.xml 中的 DTD 声明如下： 阅读全文 >>
我们在网上经常会碰到一些向导式的表单页面，比如 第一步 >> 第二步 >> 第三步…、基本信息 >> 联系方式 >> 兴趣爱好…。它们都是按类型分到多个有序的页面要你来完成填写的。当然，你也可以把它们全部罗列在一个页面里，那样用户就会感觉茫茫然，分不清主次，可能不会很好的予以配合。
然而像 Struts、WebWork 那样的 MVC 框架未提供类似的实现，都需自己采用某种方式来实现向导，可以用层的隐现方式，或逐步把填写的部分数据放 Session 中，最后汇总处理。幸运的是 Spring MVC 考虑到了这种应用需求，它提供了一个 org.springframework.web.servlet.mvc.AbstractWizardFormController 来满足你。 阅读全文 >>
当个人在撒谎时尚有害臊与尺度；而在代表着某一群体利益时，因其无具体担责人，故能弥天却不知廉耻，瞒得了众人吗？非也，只因暂无处述说罢。