垃圾收集器就是收集算法的具体实现，不同的虚拟机会提供不同的垃圾收集器。并且提供参数供用户根据自己的应用特点和要求组合各个年代所使用的收集器。本文讨论的收集器基于Sun Hotspot虚拟机1.6版。 下图中展示了jdk1.6中提供的6种作用于不同年代的收集器，两个收集器之间存在连线的话就说明它们可以搭配使用。没有最好的收集器，也没有万能的收集器，只有最合适的收集器。从Serial收集器到Parallel收集器，再到CMS收集器, G1收集器，用户线程的停顿时间在不断缩短，但是仍然没有办法完全消除。

    Servlet的线程安全问题只有在大量的并发访问时才会显现出来，并且很难发现，因此在编写Servlet程序时要特别注意。线程安全问题主要是由实例变量造成的,因此在Servlet中应避免使用实例变量。如果应用程序设计无法避免使用实例变量，那么使用同步来保护要使用的实例变量，但为保证系统的最佳性能，应该同步可用性最小的代码路径。

     在开始前给大家提3点建议! 　　不要使用System.out.println作为调试工具 　　把所有涉及到的组件日志级别激活并使用 　　使用日志分析器来读取日志

     Java中的一个byte，其范围是-128~127的，而Integer.toHexString的参数本来是int，如果不进行&0xff，那么当一个byte会转换成int时，对于负数，会做位扩展，举例来说，一个byte的-1(即0xff)，会被转换成int的-1(即0xffffffff)，那么转化出的结果就不是我们想要的了。 而0xff默认是整形，所以，一个byte跟0xff相与会先将那个byte转化成整形运算，这样，结果中的高的24个比特就总会被清0，于是结果总是我们想要的。

    第五阶段：产品成长的见证人。 也许很少人能够参与从零开始，经过创意、市场分析到产品设计的过程，在明确要做什么之前有大量的时间会花在产品探索性的工作上面。也许会做很多的产品原型，也许某些版本和功能在A/B测试之后就被放弃了，更有些产品在流传开来以前就销声匿迹了，或者很快就死在抄袭和山寨手里。产品的更迭和换代总是千辛万苦，而看得到的部分往往如此简单，但是谁知道它的历史有多曲折呢？

    我们知道HTTP协议采用“请求-应答”模式，当使用普通模式，即非KeepAlive模式时，每个请求/应答客户和服务器都要新建一个连接，完成 之后立即断开连接(HTTP协议为无连接的协议)；当使用Keep-Alive模式(又称持久连接、连接重用)时，Keep-Alive功能使客户端到服 务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。

    对象的内存分配，就是在堆上分配(但也可能经过JIT编译后被拆散为标量类型并间接地在栈上分配)，对象主要分配在新生代的Eden区上，如果启动了本地线程分配缓冲，将按线程优先在TLAB上分配。少数情况下也可能会直接分配在老年代中，分配的规则并不是百分之百固定的，其细节取决于当前使用的是哪一种垃圾收集器组合，还有虚拟机中与内存相关的参数的设置。

    算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象(如果对象在进行根搜索后发现没有与GC Roots相连接的引用链，对象将会被标记)。它是最基础的收集算法，因为后续的收集算法都是基于这种思路并对其缺点进行改进而得到的。它的主要缺点有两个：一个是效率问题，标记和清除过程的效率都不高；另外一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致，当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。