1、Web Client 向Servlet容器（Tomcat）发出Http请求

2、Servlet容器接收Web Client的请求

3、Servlet容器创建一个HttpRequest对象，将Web Client请求的信息封装到这个对象中

4、Servlet容器创建一个HttpResponse对象

5、Servlet容器调用HttpServlet对象的service方法，把HttpRequest对象与HttpResponse对象作为参数

     传给 HttpServlet对象

6、HttpServlet调用HttpRequest对象的有关方法，获取Http请求信息

7、HttpServlet调用HttpResponse对象的有关方法，生成响应数据

8、Servlet容器把HttpServlet的响应结果传给Web Client

对于Servlet容器(Tomcat)与HttpServlet是怎样进行交互的呢，看下类图

Servlet的框架是由两个Java包组成的：javax.servlet与javax.servlet.http。在javax.servlet包中定义了所有的Servlet类都必须实现或者扩展的通用接口和类。在javax.servlet.http包中定义了采用Http协议通信的HttpServlet类。Servlet的框架的核心是javax.servlet.Servlet接口，所有的Servlet都必须实现这个接口。

在Servlet接口中定义了5个方法，

其中3个方法代表了Servlet的生命周期：

1、init方法：负责初始化Servlet对象。

2、service方法：负责响应客户的请求。

3、destroy方法：当Servlet对象退出生命周期时，负责释放占用的资源。

一、创建Servlet对象的时机

1、Servlet容器启动时：读取web.xml配置文件中的信息，构造指定的Servlet对象，创建ServletConfig对象，同时将ServletConfig对象作为参数来调用Servlet对象的init方法。

2、在Servlet容器启动后：客户首次向Servlet发出请求，Servlet容器会判断内存中是否存在指定的Servlet对象，如果没有则创建它，然后根据客户的请求创建HttpRequest、       HttpResponse对象，从而调用Servlet

     对象的service方法。

3、Servlet的类文件被更新后，重新创建Servlet

      Servlet容器在启动时自动创建Servlet，这是由在web.xml文件中为Servlet设置的<load-on-startup>属性决定

      的。从中我们也能看到同一个类型的Servlet对象在Servlet容器中以单例的形式存在。

二、销毁Servlet对象的时机

1、Servlet容器停止或者重新启动：Servlet容器调用Servlet对象的destroy方法来释放资源。以上所讲的就是Servlet对象的生命周期。那么Servlet容器如何知道创建哪一个Servlet对象？

Servlet对象如何配置？实际上这些信息是通过读取web.xml配置文件来实现的。

我们来看一下web.xml文件中的Servlet对象的配置节信息

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

<servlet>

    <servlet-name>action<servlet-name>

    <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>

    <init-param>

        <param-name>config</param-name>

        <param-value>/WEB-INF/struts-config.xml</param-value>

    </init-param>

    <init-param>

        <param-name>detail</param-name>

        <param-value>2</param-value>

    </init-param>

    <init-param>

        <param-name>debug</param-name>

        <param-value>2</param-value>

    </init-param>

    <load-on-startup>2</load-on-startup>

</servlet>

<servlet-mapping>

    <servlet-name>action</servlet-name>

    <url-pattern>*.do</url-pattern>

</servlet-mapping>

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

下面对上面的配置节信息进行解析

servlet-name：Servlet对象的名称

servlet-class：创建Servlet对象所要调用的类

param-name：参数名称

param-value：参数值

load-on-startup：Servlet容器启动时加载Servlet对象的顺序

servlet-mapping/servlet-name：要与servlet中的servlet-name配置节内容对应

url-pattern：客户访问的Servlet的相对URL路径

       当Servlet容器启动的时候读取<servlet>配置节信息，根据<servlet-class>配置节信息创建Servlet对象，同时根据<init-param>配置节信息创建HttpServletConfig对象，然后执行Servlet对象的init方法，并且根据<load-on-startup>配置节信息来决定创建Servlet对象的顺序，如果此配置节信息为负数或者没有配置，那么在Servlet容器启动时，将不加载此Servlet对象。当客户访问Servlet容器时，Servlet容器根据客户访问的URL地址，通过<servlet-mapping>配置节中的<url-pattern>配置节信息找到指定的Servlet对象，并调用此Servlet对象的service方法。

为了验证下，我新建了一个web app工程，新建一个Servlet，如下:

Java代码  

1. package com.tdt.servlet;  
2.   
3. import java.io.IOException;  
4. import java.io.PrintWriter;  
5. import javax.servlet.ServletException;  
6. import javax.servlet.http.HttpServlet;  
7. import javax.servlet.http.HttpServletRequest;  
8. import javax.servlet.http.HttpServletResponse;  
9.   
10. public class TestServlet extends HttpServlet {  
11.     public void doGet(HttpServletRequest request, HttpServletResponse response)  
12.             throws ServletException, IOException {  
13.         this.doPost(request, response);  
14.     }  
15.     public void doPost(HttpServletRequest request, HttpServletResponse response)  
16.             throws ServletException, IOException {  
17.   
18.         response.setContentType("text/html");  
19.         PrintWriter out = response.getWriter();  
20.         out.println("Hello,this is a test");  
21.       
22.         out.flush();  
23.         out.close();  
24.     }  
25.   
26.     public void destroy() {  
27.         System.err.println(getServletName()+"生命周期结束");;  
28.     }  
29.       
30.     public void init() throws ServletException {  
31.         System.out.println(getServletName()+"执行初始化");  
32.     }  
33. }  

 当servlet被销毁时会在控制台上打印提示语句，不过我发现在tomcat中，只要不停止web容器，servlet是不会被销毁的。有没有什么方法，当service方法执行完毕就销毁这个servlet呢，我问了下老师，他说写一个监听器，不过我不知道怎么去实现它，如果有朋友知道实现的过程，还请赐教。

来源：struts2开发组 翻译：tianxinet（胖猴） 
Action 类: 
• Struts1要求Action类继承一个抽象基类。Struts1的一个普遍问题是使用抽象类编程而不是接口。 
• Struts 2 Action类可以实现一个Action接口，也可实现其他接口，使可选和定制的服务成为可能。Struts2提供一个ActionSupport基类去实现 常用的接口。Action接口不是必须的，任何有execute标识的POJO对象都可以用作Struts2的Action对象。 
线程模式: 
• Struts1 Action是单例模式并且必须是线程安全的，因为仅有Action的一个实例来处理所有的请求。单例策略限制了Struts1 Action能作的事，并且要在开发时特别小心。Action资源必须是线程安全的或同步的。 
• Struts2 Action对象为每一个请求产生一个实例，因此没有线程安全问题。（实际上，servlet容器给每个请求产生许多可丢弃的对象，并且不会导致性能和垃圾回收问题） 
Servlet 依赖: 
• Struts1 Action 依赖于Servlet API ,因为当一个Action被调用时HttpServletRequest 和 HttpServletResponse 被传递给execute方法。 
• Struts 2 Action不依赖于容器，允许Action脱离容器单独被测试。如果需要，Struts2 Action仍然可以访问初始的request和response。但是，其他的元素减少或者消除了直接访问HttpServetRequest 和 HttpServletResponse的必要性。 
可测性: 
• 测试Struts1 Action的一个主要问题是execute方法暴露了servlet API（这使得测试要依赖于容器）。一个第三方扩展－－Struts TestCase－－提供了一套Struts1的模拟对象（来进行测试）。 
• Struts 2 Action可以通过初始化、设置属性、调用方法来测试，“依赖注入”支持也使测试更容易。 
捕获输入: 
• Struts1 使用ActionForm对象捕获输入。所有的ActionForm必须继承一个基类。因为其他JavaBean不能用作ActionForm，开发者经常创建多余的类捕获输入。动态Bean（DynaBeans）可以作为创建传统ActionForm的选择，但是，开发者可能是在重新描述(创建)已经存在的JavaBean（仍然会导致有冗余的javabean）。 
• Struts 2直接使用Action属性作为输入属性，消除了对第二个输入对象的需求。输入属性可能是有自己(子)属性的rich对象类型。Action属性能够通过 web页面上的taglibs访问。Struts2也支持ActionForm模式。rich对象类型，包括业务对象，能够用作输入/输出对象。这种 ModelDriven 特性简化了taglib对POJO输入对象的引用。 
表达式语言： 
• Struts1 整合了JSTL，因此使用JSTL EL。这种EL有基本对象图遍历，但是对集合和索引属性的支持很弱。 
• Struts2可以使用JSTL，但是也支持一个更强大和灵活的表达式语言－－"Object Graph Notation Language" (OGNL). 
绑定值到页面（view）: 
• Struts 1使用标准JSP机制把对象绑定到页面中来访问。 
• Struts 2 使用 "ValueStack"技术，使taglib能够访问值而不需要把你的页面（view）和对象绑定起来。ValueStack策略允许通过一系列名称相同但类型不同的属性重用页面（view）。 
　 
类型转换： 
• Struts 1 ActionForm 属性通常都是String类型。Struts1使用Commons-Beanutils进行类型转换。每个类一个转换器，对每一个实例来说是不可配置的。 
• Struts2 使用OGNL进行类型转换。提供基本和常用对象的转换器。 
校验： 
• Struts 1支持在ActionForm的validate方法中手动校验，或者通过Commons Validator的扩展来校验。同一个类可以有不同的校验内容，但不能校验子对象。 
• Struts2支持通过validate方法和XWork校验框架来进行校验。XWork校验框架使用为属性类类型定义的校验和内容校验，来支持chain校验子属性 
Action执行的控制： 
• Struts1支持每一个模块有单独的Request Processors（生命周期），但是模块中的所有Action必须共享相同的生命周期。 
• Struts2支持通过拦截器堆栈（Interceptor Stacks）为每一个Action创建不同的生命周期。堆栈能够根据需要和不同的Action一起使用。

本文主要以spring ioc容器基本代码骨架为切入点，理解ioc容器的基本代码组件结构，各代码组件细节剖析将放在后面的学习文章里。

 http://www.iteye.com/topic/1113459

关于IOC容器

IoC容器：最主要是完成了完成对象的创建和依赖的管理注入等等。

先从我们自己设计这样一个视角来考虑：

所谓控制反转，就是把原先我们代码里面需要实现的对象创建、依赖的代码，反转给容器来帮忙实现。那么必然的我们需要创建一个容器，同时需要一种描述来让容器知道需要创建的对象与对象的关系。这个描述最具体表现就是我们可配置的文件。

对象和对象关系怎么表示？

可以用xml，properties文件等语义化配置文件表示。

描述对象关系的文件存放在哪里？

可能是classpath，filesystem，或者是URL网络资源，servletContext等。

回到正题，有了配置文件，还需要对配置文件解析。

不同的配置文件对对象的描述不一样，如标准的，自定义声明式的，如何统一？ 在内部需要有一个统一的关于对象的定义，所有外部的描述都必须转化成统一的描述定义。

如何对不同的配置文件进行解析？需要对不同的配置文件语法，采用不同的解析器。

基于以上问题，对应过来，刚好是 spring ioc 容器抽象的的几个主要接口：

Resource

BeanDefinition

BeanDefinitionReader

BeanFactory

ApplicationContext

以上五个都是接口，都有各式各样的实现，正是这5个接口定义了spring ioc容器的基本代码组件结构。而其组件各种实现的组合关系组成了一个运行时的具体容器。

各代码组件详解

1.Resource

是对资源的抽象，每一个接口实现类都代表了一种资源类型，如ClasspathResource、URLResource，FileSystemResource等。每一个资源类型都封装了对某一种特定资源的访问策略。它是spring资源访问策略的一个基础实现，应用在很多场景。

具体可以参考文章:

Spring 资源访问剖析和策略模式应用

http://www.ibm.com/developerworks/cn/java/j-lo-spring-resource/index.html

2.BeanDefinition

用来抽象和描述一个具体bean对象。是描述一个bean对象的基本数据结构。

3.BeanDefinitionReader

BeanDefinitionReader将外部资源对象描述的bean定义统一转化为统一的内部数据结构BeanDefinition。对应不同的描述需要有不同的Reader。如XmlBeanDefinitionReader用来读取xml描述配置的bean对象。

4.BeanFactory

用来定义一个很纯粹的bean容器。它是一个bean容器的必备结构。同时和外部应用环境等隔离。BeanDefinition是它的基本数据结构。它维护一个BeanDefinitions Map,并可根据BeanDefinition的描述进行bean的创建和管理。

5.ApplicationContext

从名字来看叫应用上下文，是和应用环境息息相关的。没错这个就是我们平时开发中经常直接使用打交道的一个类，应用上下文，或者也叫做spring容器。其实它的基本实现是会持有一个BeanFactory对象，并基于此提供一些包装和功能扩展。为什么要这么做呢？因为BeanFactory实现了一个容器基本结构和功能，但是与外部环境隔离。那么读取配置文件，并将配置文件解析成BeanDefinition，然后注册到BeanFactory的这一个过程的封装自然就需要ApplicationContext。ApplicationContext和应用环境细细相关，常见实现有ClasspathXmlApplicationContext,FileSystemXmlApplicationContext,WebApplicationContext等。Classpath、xml、FileSystem、Web等词都代表了应用和环境相关的一些意思，从字面上不难理解各自代表的含义。

当然ApplicationContext和BeanFactory的区别远不止于此，有：

1.  资源访问功能：在Resource和ResourceLoader的基础上可以灵活的访问不同的资源。

2.  支持不同的信息源。

3.  支持应用事件：继承了接口ApplicationEventPublisher，这样在上下文中为bean之间提供了事件机制。

……

以上5个组件基本代表了ioc容器的一个最基本组成，而组件的组合是放在ApplicationContext的实现这一层来完成。

以ClasspathXmlApplicationContext 容器实现为例，其组合关系如下：

ClassPathXmlApplicationContext的refresh() 方法负责完成了整个容器的初始化。

为什么叫refresh？也就是说其实是刷新的意思，该IOC容器里面维护了一个单例的BeanFactory，如果bean的配置有修改，也可以直接调用refresh方法，它将销毁之前的BeanFactory，重新创建一个BeanFactory。所以叫refresh也是能理解的。

以下是Refresh的基本步骤：
1.把配置xml文件转换成resource。resource的转换是先通过ResourcePatternResolver来解析可识别格式的配置文件的路径
(如"classpath*:"等)，如果没有指定格式，默认会按照类路径的资源来处理。 
2.利用XmlBeanDefinitionReader完成对xml的解析，将xml Resource里定义的bean对象转换成统一的BeanDefinition。
3.将BeanDefinition注册到BeanFactory，完成对BeanFactory的初始化。BeanFactory里将会维护一个BeanDefinition的Map。

当getBean的时候就会根据调用BeanFactory，根据bean的BeanDifinition来实例化一个bean。当然根据bean的lazy-init、protetype等属性设置不同以上过程略有差别。

refresh()代码如下：

Java代码  

1. public void refresh() throws BeansException, IllegalStateException {  
2.     synchronized (this.startupShutdownMonitor) {  
3.         // Prepare this context for refreshing.  
4.         prepareRefresh();  
5.   
6.         // Tell the subclass to refresh the internal bean factory.  
7.         ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();  
8.   
9.         // Prepare the bean factory for use in this context.  
10.         prepareBeanFactory(beanFactory);  
11.   
12.         try {  
13.             // Allows post-processing of the bean factory in context subclasses.  
14.             postProcessBeanFactory(beanFactory);  
15.   
16.             // Invoke factory processors registered as beans in the context.  
17.             invokeBeanFactoryPostProcessors(beanFactory);  
18.   
19.             // Register bean processors that intercept bean creation.  
20.             registerBeanPostProcessors(beanFactory);  
21.   
22.             // Initialize message source for this context.  
23.             initMessageSource();  
24.   
25.             // Initialize event multicaster for this context.  
26.             initApplicationEventMulticaster();  
27.   
28.             // Initialize other special beans in specific context subclasses.  
29.             onRefresh();  
30.   
31.             // Check for listener beans and register them.  
32.             registerListeners();  
33.   
34.             // Instantiate all remaining (non-lazy-init) singletons.  
35.             finishBeanFactoryInitialization(beanFactory);  
36.   
37.             // Last step: publish corresponding event.  
38.             finishRefresh();  
39.         }  
40.   
41.         catch (BeansException ex) {  
42.             // Destroy already created singletons to avoid dangling resources.  
43.             beanFactory.destroySingletons();  
44.   
45.             // Reset 'active' flag.  
46.             cancelRefresh(ex);  
47.   
48.             // Propagate exception to caller.  
49.             throw ex;  
50.         }  
51.     }  
52. }  

 以上的obtainFreshBeanFactory是很关键的一个方法，里面会调用loadBeanDefinition方法，如下：

Java代码  

1. protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws IOException {  
2.     // Create a new XmlBeanDefinitionReader for the given BeanFactory.  
3.     XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);  
4.   
5.     // Configure the bean definition reader with this context's  
6.     // resource loading environment.  
7.     beanDefinitionReader.setResourceLoader(this);  
8.     beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));  
9.   
10.     // Allow a subclass to provide custom initialization of the reader,  
11.     // then proceed with actually loading the bean definitions.  
12.     initBeanDefinitionReader(beanDefinitionReader);  
13.     loadBeanDefinitions(beanDefinitionReader);  
14. }  

 LoadBeanDifinition方法很关键，这里特定于整个IOC容器，实例化了一个XmlBeanDefinitionReader来解析Resource文件。关于Resource文件如何初始化和xml文件如何解析都在

Java代码  

1. loadBeanDefinitions(beanDefinitionReader);  

 里面的层层调用完成，这里不在累述。

小结 

Spring的扩展性是毋庸置疑的，学习spring的设计是一个很好的实践理论结合。主要个人觉得有几点：

1.  框架顶层的设计有着很好的抽象，遵循面向接口编程的规范。Resource、BeanFactory、ApplicationContext都是非常好的接口抽象，非常明确的定义了该组件的一些功能。

2.  利用组合模式。

3.  个组件的实现里大量使用了模板方法模式，提升了同一组件代码的复用性。

4.  各种设计保留了扩展的接口，很多基于spring的框架都可以很容易的介入实现了自己的一些扩展。

5.  框架里采用里很多经典的设计模式，如代理、装饰、策略等等。

先来看下一X宝经典配置：

/opt/taobao/java/bin/java -Dprogram.name=run.sh –server

 -Xms4g           //指定 jvm 的最小 heap 大小 （-Xms默认是物理内存的1/4)

 -Xmx4g           //指定 jvm 的最大 heap 大小

 -Xmn2g

 -Xss1m

 -XX:PermSize=96m

 -XX:MaxPermSize=256m

 -XX:SurvivorRatio=10

 -XX:+HeapDumpOnOutOfMemoryError    //

 -XX:HeapDumpPath=/home/admin/logs/java.hprof -verbose:gc -Xloggc:/home/admin/logs/gc.log

 -XX:+PrintGCDetails

 -XX:+PrintGCDateStamps

 -XX:+UseConcMarkSweepGC

 -XX:+UseCMSCompactAtFullCollection

 -XX:CMSInitiatingOccupancyFraction=80

 -XX:+UseCompressedOops

 -XX:+DisableExplicitGC

 -Djava.awt.headless=true

 -Dsun.net.client.defaultConnectTimeout=10000

 -Dsun.net.client.defaultReadTimeout=30000

 -Djava.net.preferIPv4Stack=true

 -Djava.endorsed.dirs=/opt/taobao/jboss/lib/endorsed

 -classpath /opt/taobao/jboss/bin/run.jar:/opt/taobao/java/lib/tools.jar org.jboss.Main -b 0.0.0.0 -Djboss.server.home.dir=/home/admin/purdecision/.default -Djboss.server.home.url=file:/home/admin/purdecision/.default

这二年来这一堆东西我从来没有怀疑过，“绝对正确完美”，据说是X宝的标配。以至于从来没有去分析了解过（一知半解），可能真的是惰性使然，也可能“忙”吧。无意中看到有人在博客里写到 “温故知新”，就像有人说读think in java一样每一回都有新的发现。下面就分析一下为什么要设置这些参数，有何意义。

上面参数说明：

-Xmx4g :

 指定 jvm 的最大 heap 大小，默认值为物理内存的1/4，最佳设值应该视物理内存大小及计算机内其他内存开销而定

-Xms4g :

 指定 jvm 的最小 heap 大小。些值设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存

-Xmn2g :

设置年轻代大小为2G。整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般

固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推

荐配置为整个堆的3/8。(按此说应设置为1.5G)

-Xss1m

每个线程堆栈大小为1M. 根据应用的线程所需内存大小进行调整。在相同物理内存下,减小这个值能生成更多的线程。（本机由于forest的原因-Xss2m，原因1：物理内存过小 2：window线程不能太多 猜的）

-XX:PermSize=96m

用于存放静态文件，如今Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或

者调用一些class，例如Hibernate等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新

增的类。持久代大小通过-XX:MaxPermSize=<N>进行设置

-XX:PermSize=64MB 最小尺寸，初始分配
-XX:MaxPermSize=256MB 最大允许分配尺寸，按需分配
过小会导致：java.lang.OutOfMemoryError: PermGen space

MaxPermSize缺省值和-server -client选项相关。
-server选项下默认MaxPermSize为64m
-client选项下默认MaxPermSize为32m

（为什么不是64M 可能是webx设置的持久代空间比较多）

-XX:SurvivorRatio=10

（SurvivorRatio=4设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor

区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6）

这里设置为10也就是说一个Survivor区占整个年轻代的1/12，这个参数是否能小一点，毕竟我们的应用中没有创建很大的对像。

这个值设了有什么用？

上面配置中-Xmn2g 年轻代大小，SurvivorRatio为10时 ：Eden超过1.66G时触发minor gc(young generation)

我的应用gc 日志一直在young gc 就是如此，看来我的应用 eden区还是设的很大的。

 -XX:+HeapDumpOnOutOfMemoryError

参数表示当JVM发生OOM时，自动生成DUMP文件。 

-XX:HeapDumpPath=${目录}参数表示生成DUMP文件的路径，也可以指定文件名称，例如：-XX:HeapDumpPath=${目录}/java_heapdump.hprof。如果不指定文件名，默认为：java_<pid>_<date>_<time>_heapDump.hprof。

-XX:+PrintGCDetails：

输出形式：[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs] [GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured:

112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]

-XX:+PrintGCTimeStamps -XX:+PrintGC：PrintGCTimeStamps可与上面两个混合使用

输出形式：11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]

-XX:+UseConcMarkSweepGC  

设置并发收集器

可以保证大部分工作都并发进行（应用不停止），垃圾回收只暂停很少的时间，此收集器适合对响应时间要求

比较高的中、大规模应用。使用-XX:+UseConcMarkSweepGC打开。

并发收集器主要减少年老代的暂停时间，他在应用不停止的情况下使用独立的垃圾回收线程，跟踪可达对

象。在每个年老代垃圾回收周期中，在收集初期并发收集器 会对整个应用进行简短的暂停，在收集中还会再暂

停一次。第二次暂停会比第一次稍长，在此过程中多个线程同时进行垃圾回收工作。

CMS采用的基础算法是：标记—清除 所有CMS不会整理、压缩堆空间。这样就会有一个问题：经过CMS收集的堆会产生空间碎片

-XX:CMSInitiatingOccupancyFraction=80

启动并发收集器：因为并发收集在应用运行时进行收集，所以必须保证收集完成之前有足够的内存空间供程

序使用，否则会出现“Concurrent Mode Failure”。通过设置-XX:CMSInitiatingOccupancyFraction=<N>

指定还有多少剩余堆时开始执行并发收集

-XX:+UseCMSCompactAtFullCollection：

打开对年老代的压缩。可能会影响性能，但是可以消除碎片

XX:+UseCompressedOops

通常64位JVM消耗的内存会比32位的大1.5倍，这是因为对象指针在64位架构下，长度会翻倍（更宽的寻址）。
对于那些将要从32位平台移植到64位的应用来说，平白无辜多了1/2的内存占用，这是开发者不愿意看到的。
幸运的是，从JDK 1.6 update14开始，64 bit JVM正式支持了 -XX:+UseCompressedOops 这个可以压缩指针，起到节约内存占用的新参数

-XX:-DisableExplicitGC

将会忽略手动调用GC的代码，如：System.gc()，将-DisableExplicitGC， 改成+DisableExplicitGC即为启用，默认为启用，什么也不写，默认是加号，但是系统内部默认的并不是什么都启用

至此为什么Xmx与xms 一样，为什么用CMS（并发收集器），为什么用了cms 要使用-XX:+UseCMSCompactAtFullCollection，为什么用XX:+UseCompressedOops等等，相信大家和我一样有所了解。不过对于有些还是不清楚理解有误，可能还要来来回回捣腾，不足之处请大家补充。