本机已经安装了jdk1.6，而比较早期的项目需要依赖jdk1.5，于是同时在本机安装了jdk1.5和jdk1.6. 

 安装jdk1.5前，执行java -version得到

java version "1.6.0_38"
Java(TM) SE Runtime Environment (build 1.6.0_38-b05)
Java HotSpot(TM) 64-Bit Server VM (build 20.13-b02, mixed mode)

安装完jdk1.5,并修改环境变量JAVA_HOME为D:\devSoftware\jdk1.5.再执行 java -version时，依然显示：

java version "1.6.0_38"
Java(TM) SE Runtime Environment (build 1.6.0_38-b05)
Java HotSpot(TM) 64-Bit Server VM (build 20.13-b02, mixed mode)

看上去，新的环境变量JAVA_HOME=D:\devSoftware\jdk1.5并没有生效。 在网上找了很多资料才发现：

      在安装JDK1.6时（本机先安装jdk1.6再安装的jdk1.5），自动将java.exe、javaw.exe、javaws.exe三个可执行文件复制到了C:\Windows\System32目录，由于这个目录在WINDOWS环境变量中的优先级高于JAVA_HOME设置的环境变量优先级

解决方案：将java.exe,javaw.exe,javaws.exe删除即可。开启新的命令行窗口，再执行java -version时，就得到了期望中的结果

java version "1.5.0_17"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_17-b04)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_17-b04, mixed mode)

2 做产品需求，而不是用户需求；

3 要锦上添花，而不是画蛇添足；

4 追求人性化，而不是追求完美。

产品经理是个很奇怪的岗位，好像大多数人都能做，因为每个人对某个产品都有自己的看法，都能提出一些意见和想法，甚至能设计实现原理；也好像大多数人都做不好产品经理，因为互联网上成千上万个产品，大部分是垃圾，没几个产品是用户真心觉得很不错的。

我做产品经理，还不到两年，以前十来年一直在做技术。之前做技术的时候，我很看不上产品经理。当时想：产品经理自己什么都实现不了，每天就是提点想法，而且想法还经常不靠谱，如果哪天裁员，产品经理的位置最危险了；但等我转来做了产品经理，想法发生了根本的变化：嗯，产品经理太重要的，一个产品的未来就决定在产品经理身上。

你问我现在如何看待技术人员？嘿嘿，我现在觉得，技术就是一把刀，让它杀谁就杀谁！当然，这只是开玩笑。一个好的技术团队对于产品经理来说，那是相当重要。

对如何做产品经理，我还真的是小学生，自己负责的淘宝搜索最近两年也没什么大提升。特别是看了周鸿祎、张小龙关于对产品的一些访谈以后，我更发现自己在这方面的差距。

不过我有个优点，就是善于学习、思考、总结并分享。而且作为一个外行进入到这个领域，观察的角度也会不一样。这一年多下来，也找到一些感觉，发现周围的一些产品经理，容易走入一些误区，分享给大家。

1 做产品经理，而不是功能经理。

这句话我最早是听天猫总裁逍遥子说的，当时没有感觉，现在发现非常有道理，因为周围太多的产品经理实际上是在做一名功能经理。

他们只是不停的在接产品功能需求，然后不停实现产品功能。缺登录，设计一个登录框；没有数据，找某个平台打通一下；管理不方便，设计一个工具来管理；页面不美观，重新规划一下页面结构……

功能经理，每天都很忙，关注还有多少需求在后面排队，需求方是否得到满足。而用户体验到底如何，功能是否真的真有价值，是否可以更加完美，功能经理很少关心。当有人抱怨某个功能不爽的时候，他会说：

这个功能我已经有了啊，你说体验不太好？没办法，工程师资源太紧张啊，你说为啥设计的这么别扭？kao，想起来就来气，大老板非要求这样啊，我们也只能这样设计，没办法！

他经常表达的语气是他也不得已而为之，把责任都推到其他人身上。

然而做一个合格的产品经理，需要关注用户的体验，真正关注用户的反馈，关注数据的质量，关注每一个细节。就像买一双鞋一样，不只是能穿，还要考虑是否合脚，是否舒服，款式是否漂亮。

有一次开会，淘宝的总裁语嫣姐姐说了一句很朴素但很有道理的一句话：产品能用和好用完全不是一回事！

(大家不用批评淘宝搜索啊，我知道很多地方还不好用。大家再给我点时间，我也认识到这个问题不是......)

2 实现产品需求，而不是用户需求。

这个话题很有意思。当你问用户需要什么的时候，他会回答他需要一匹更快的马。乔布斯说，永远不要问用户想要什么！因为用户都是傻瓜，不知道自己想要什么。

这其实是产品经理经常把用户需求当成产品需求。对所有用户说的，他们没错，提的都是自己的期望，不是一个产品需求。前些天有张小龙的采访，张小龙说他不看用户的数据。其实张小龙很关心用户的需求，我和张小龙在一个群里，如果有人在群里提一些微信使用不爽的功能，张小龙会很快给出反馈。

这些产品大神们，背后的意思是，不应该简单满足用户需求，而应该思考把用户需求提炼成产品需求。当一个产品的用户有上百万上千万的时候，产品需求的理解和提炼，就相当重要。

这个道理比较容易理解，不做多解释。

3 要锦上添花，而不是画蛇添足。

互联网的发展，让很多互联网产品经理有个惯性：做产品迭代要快。快速上线，快速修改。这里也有误区，对于一些基本功能，确实要快速上线，快速迭代。因为有市场竞争，需要快速切入市场，获得用户。然而大部分的产品经理，没有机会从零开始设计一个新产品，大部分时候在现有的产品上做升级或优化。这时设计的很多功能，都是锦上添花的功能，还真不能太快。

锦上添花的功能，同样重要，会让产品更好玩，更有意思，更有特点。例如微信最早设计的摇一摇功能、朋友圈功能。微博的微刊功能、之前的送礼物的功能。

问题在于，锦上添花，添上去的一定是一朵花，说得俗一点，不能添上去是一坨屎。如果是后者，那么就有点画蛇添足了，或者成了鸡肋功能。

什么是一朵花？就是功能添加上去以后，会让用户眼前一亮。给人有“哇！！！”的感觉……

遗憾的是淘宝搜索之前的很多功能添上去的都不是一朵花，上线了太多的画蛇添足的功能。这些功能一旦上线，就很难下线。因为当你产品的用户群有上亿的时候，再烂的一个功能，每天也会有几十万用户在使用。一旦你下线，会有很多人很不爽。

淘宝搜索的同店购就有点这个味道。技术实现成本高，体验一般，用的人也不多。有一段时间我们把这个功能隐藏起来了，有人在微博上说：

妈的，我现在最想做的事情，就是找把刀杀个淘宝搜索的产品经理来解解恨，我居然死活找不到我最常用的同店购了！

画蛇添足的功能越多，让产品背负的垃圾就越多，造成好的功能没有资源做，差的功能又无法下线。

4 追求人性化，而不是追求完美。

很多产品经理，追求完美。这是作为产品经理很好的品质，然而，有一点却经常被产品经理忽视，产品的人性化。

永远没有完美的产品，特别是当一个产品的用户量到达上百万上千万的时候。用户的喜好千差万别。如何让用户能喜欢产品的优点的同时能容忍产品的缺点？

大家看选美大赛获胜的美女，经常会有感叹，为什么这么丑还能得前三啊！是因为评委的口味太特别？当然有一部分评委原因，但更多原因在于，大家每个人的审美观不一样。大家是把选美冠军作为一个完美的人来评判。

实际上，无论选出谁是冠军，都会有人觉得难看。任何一个产品，无论产品经理推出多么好用的功能，都会有人不喜欢！

然而，大家对待周围的朋友，就不会用选美的标准要求他们，他们有明显的缺点，但也有很多值得欣赏的地方。大家订阅鬼脚七的微信，绝大部分人不会期望，鬼脚七每天的文章都会符合自己的口味。有人不看文章，只看看【7哥闲谈】也会觉得很有意思。为什么？因为大家不会期待鬼脚七这个账号是个完美的账号，把鬼脚七作为一个朋友在看待。鬼脚七有缺点，也有优点。

如果能让用户把我们的产品当成周围的朋友来看待呢？感觉会完全不一样。

淘宝有个做运营的同事有一天跟我感叹说：我忽然觉得攻城狮们离我好近，每个攻城狮内心都住着个诗人！我问为什么会忽然有这种感觉？她说有一天晚上，发现在淘宝内部一个TMS系统的标题栏上忽然多了一句话：

每个人的压力，少部分来自生存，大部分来自攀比。

就这一句话，让用户感觉到了产品背后的那位工程师。还记得微信有个版本的欢迎页面上的文字吗：

少发微信，多和朋友见见面！

就这一句话，让我感觉到产品背后的那群人的心理活动。微信的一些小瑕疵，我也能容忍。

就是这句话，我喜欢上了微信。

人性化，是不是让产品开始具有了灵魂？

如何让产品更加人性化？如何让淘宝搜索更加人性化？是我最近一直在思考的问题。我定义2013年搜索的关键词：专业和有趣。希望2013年能让更多的人把淘宝搜索当成一个朋友，而不是一个工具。

写了这么多，回头看看我这篇文章，好像没有什么产品设计方法，只是一些思考，仅此而已。

作者介绍：

鬼脚七，一个简单的人，分享电商资讯、搜索变化、淘宝动态、产品设计、管理心得、生活感悟；偶尔文艺，偶尔深沉。做一个有思想的人！微信账号: taobaoguijiaoqi 加为好友后回复 m 可以看到作者之前的所有文章。

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呢，我问了下老师，他说写一个监听器，不过我不知道怎么去实现它，如果有朋友知道实现的过程，还请赐教。

 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.  框架里采用里很多经典的设计模式，如代理、装饰、策略等等。

/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等等，相信大家和我一样有所了解。不过对于有些还是不清楚理解有误，可能还要来来回回捣腾，不足之处请大家补充。