分布式项目在每个web节点肯定需要充分利用节点性能。一直觉得优化虽然能够一定程度上提供效率但是和默认配置差别感觉上应该不会相差太大，直到看到一个博文称“系统平均性能提升达20倍”才好好看了看这一方面的东西。如下总结：
目录：
1.容器connector参数优化
2.容器executor参数优化
3.相关参数理解
4.io模式优化
5.jvm参数优化
6.常见java内存溢出
<!----分割线---->
1.容器executor参数优化
bio原始方式是一个连接一个线程。启用线程池来优化线程资源。在配置中，Executor可以单独配置，并被整个Tomcat共享。如果不配置，则Connector组件将使用自己默认的实现。
配置文件conf/server.xml：
<Executor
name="tomcatThreadPool"
namePrefix="catalina-exec-"
maxThreads="500"
maxThreads="500"
minSpareThreads="20"
maxIdleTime="60000" />
配置说明：
最大线程500，最小空闲线程数20，线程最大空闲时间60秒。
修改connector相关参数：
<Connector
executor="tomcatThreadPool"
port="80"
protocol="HTTP/1.1"
maxThreads="600"
minSpareThreads="100"
maxSpareThreads="300"
connectionTimeout="60000"
keepAliveTimeout="15000"
maxKeepAliveRequests="1"
/>
port="80"
protocol="HTTP/1.1"
maxThreads="600"
minSpareThreads="100"
maxSpareThreads="300"
connectionTimeout="60000"
keepAliveTimeout="15000"
maxKeepAliveRequests="1"
/>
可选参数说明：
maxThreads：Tomcat可创建的最大的线程数，每一个线程处理一个请求；
minSpareThreads：最小备用线程数，tomcat启动时的初始化的线程数；
maxSpareThreads：最大备用线程数，一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程；
acceptCount：指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，就是被排队的请求数，超过这个数的请求将拒绝连接。
connnectionTimeout：网络连接超时，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。
enableLookups:是否允许DNS查询
maxThreads：Tomcat可创建的最大的线程数，每一个线程处理一个请求；
minSpareThreads：最小备用线程数，tomcat启动时的初始化的线程数；
maxSpareThreads：最大备用线程数，一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程；
acceptCount：指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，就是被排队的请求数，超过这个数的请求将拒绝连接。
connnectionTimeout：网络连接超时，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。
enableLookups:是否允许DNS查询
2.容器connector参数优化
tomcat不同版本配置参数有差别官网可查看。配置文件conf/server.xml：
默认配置：
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
connectionTimeout="20000"
redirectPort="8443" />
修改后的配置：
<Connector
executor="tomcatThreadPool"
port="80"
port="80"
protocol="HTTP/1.1"
connectionTimeout="60000"
keepAliveTimeout="15000"
maxKeepAliveRequests="1"
redirectPort="443"
maxHttpHeaderSize="8192"
connectionTimeout="60000"
keepAliveTimeout="15000"
maxKeepAliveRequests="1"
redirectPort="443"
maxHttpHeaderSize="8192"
URIEncoding="UTF-8"
enableLookups="false"
acceptCount="100"
disableUploadTimeout="true"/>
可选参数说明：
connectionTimeout ：网络连接超时，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。
keepAliveTimeout ：长连接最大保持时间（毫秒）。此处为15秒。
maxKeepAliveRequests ：最大长连接个数（1表示禁用，-1表示不限制个数，默认100个。一般设置在100~200之间）
maxHttpHeaderSize ：http请求头信息的最大程度，超过此长度的部分不予处理。一般8K。
URIEncoding ：指定Tomcat容器的URL编码格式。
acceptCount ：指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理，默认为10个。
disableUploadTimeout ：上传时是否使用超时机制
enableLookups ：是否反查域名，取值为：true或false。为了提高处理能力，应设置为false
bufferSize ：定义要为由此连接器创建的输入流提供的缓冲区的大小（字节）。默认情况下，提供2048字节的缓冲区。
maxSpareThreads ：做多空闲连接数，一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程
maxThreads ：最多同时处理的连接数，Tomcat使用线程来处理接收的每个请求。这个值表示Tomcat可创建的最大的线程数。
minSpareThreads ：最小空闲线程数，Tomcat初始化时创建的线程数。
minProcessors ：最小空闲连接线程数，用于提高系统处理性能，默认值为10。（用于Tomcat4中）
maxProcessors：最大连接线程数，即：并发处理的最大请求数，默认值为75。（用于Tomcat4中）
以上基于tomcat6的配置。tomcat8配置参数大同小异。如下：
1)单一配置方式
<!--连接器设置-->
<Connector
port="8080"
protocol="org.apache.coyote.http11.Http11AprProtocol" --协议类型
disableUploadTimeout="true"
keepAliveTimeout="20000"
connectionTimeout="20000" --已接受，但未被处理的请求的等待超时时间 ms
redirectPort="8443" --安全通信的转发端口
URIEncoding="UTF-8"--URL编码字符集
minSpareThreads="100" --默认初始化和保持空闲的线程数
enableLookups="false"--关闭DNS反向查询
useURIValidationHack="false" --关闭不必要的检查
maxThreads="1000" --处理请求线程的最大数目 未配置为200 此属性会被忽略
acceptCount="1000" --所用可能的线程都在使用时传入连接请求的最大长度
disableUploadTimeout="true" --设置允许更长的超时连接
maxConnections="1000"--接受和处理的最大连接数(nio/nio2 1000，apr 8192)
maxHttpHeaderSize="8192"--请求和响应http头的最大大小 8k
tcpNoDelay="true" --tcp不延迟
compression="on"--是否启用压缩 on off force
compressionMinSize="2048" --压缩前数据最小值 2k byte
noCompressionUserAgents="gozilla,traviata" --设置哪些浏览器不压缩
compressableMimeType="text/html,text/xml,text/css,application/javascript,text/plain" --设置压缩的文件类型
/>
<!--连接器设置-->
<Connector
port="8080"
protocol="org.apache.coyote.http11.Http11AprProtocol" --协议类型
disableUploadTimeout="true"
keepAliveTimeout="20000"
connectionTimeout="20000" --已接受，但未被处理的请求的等待超时时间 ms
redirectPort="8443" --安全通信的转发端口
URIEncoding="UTF-8"--URL编码字符集
minSpareThreads="100" --默认初始化和保持空闲的线程数
enableLookups="false"--关闭DNS反向查询
useURIValidationHack="false" --关闭不必要的检查
maxThreads="1000" --处理请求线程的最大数目 未配置为200 此属性会被忽略
acceptCount="1000" --所用可能的线程都在使用时传入连接请求的最大长度
disableUploadTimeout="true" --设置允许更长的超时连接
maxConnections="1000"--接受和处理的最大连接数(nio/nio2 1000，apr 8192)
maxHttpHeaderSize="8192"--请求和响应http头的最大大小 8k
tcpNoDelay="true" --tcp不延迟
compression="on"--是否启用压缩 on off force
compressionMinSize="2048" --压缩前数据最小值 2k byte
noCompressionUserAgents="gozilla,traviata" --设置哪些浏览器不压缩
compressableMimeType="text/html,text/xml,text/css,application/javascript,text/plain" --设置压缩的文件类型
/>
一般只需要进行上面的配置即可
2)使用线程池的方式
<!--连接池设置-->
<Executor
name="tomcatThreadPool" --线程池名
namePrefix="catalina-exec-" --线程名称前缀 namePrefix+threaNumber
maxThreads="1000" --池中最大线程数
minSpareThreads="100" --活跃线程数 会一直存在
maxIdleTime="60000" --线程空闲时间，超过该时间，线程会被销毁 ms
maxQueueSize="Integer.MAX_VALUE" --被执行前线程的排队数目
prestartminSpareThreads="false" --启动线程池时，是否启用minSpareThreads部分线程
threadPriority="5" --线程池中线程优先级 1~10
className="org.apache.catalina.core.StandardThreadExecutor" --线程实现类 自定义线程需时间 org.apache.catalina.Executor类
/>
<!--当配置了连接池时，需要配置该连接器-->
<Connector
executor="tomcatThreadPool" --线程池名
port="8080"
protocol="org.apache.coyote.http11.Http11AprProtocol"
connectionTimeout="20000"
redirectPort="8443" />
3.线程池相关参数理解
通过上面配置可以看到线程池相关参数和连接参数之间的微妙关系。
tomcat处理连接流程图：
OS与客户端握手并建立连接，并将建立的连接放入完成队列，不妨叫Acceptor Queque。这个队列的长度就是Connector的acceptCount值。
Tomcat中的acceptor线程，不断从Acceptor Queque中获取连接。
Acceptor Queque队列中没有连接，Acceptor线程继续监视
Acceptor Queque队列中有新连接，Acceptor线程将检查当前的连接数是否超过了maxConnections
如果超过maxConnections，则阻塞。直到连接数小于maxConnections，acceptor线程将请求交由Executor负责执行。
Executor将分配worker线程来处理请求数据的读取，处理（servlet的执行）以及响应。
Tomcat中的acceptor线程，不断从Acceptor Queque中获取连接。
Acceptor Queque队列中没有连接，Acceptor线程继续监视
Acceptor Queque队列中有新连接，Acceptor线程将检查当前的连接数是否超过了maxConnections
如果超过maxConnections，则阻塞。直到连接数小于maxConnections，acceptor线程将请求交由Executor负责执行。
Executor将分配worker线程来处理请求数据的读取，处理（servlet的执行）以及响应。
参数理解：
acceptCount：
acceptCount 实际上是Bind Socket时候传递的backlog值，在linux平台下含义是已经建立连接还没有被应用获取的连接队列最大长度。此时，如果请求个数达到了acceptCount，新进的请求将抛出refuse connection.
maxConnections:
顾名思义，即Tomcat允许的同时存在的最大连接数。默认BIO模式下，这个数值等于maxThreads，即最大线程数。超过这个值后，acceptor线程被Block。新进入的连接将由acceptCount控制。当当前连接数小于这个数值时，acceptor线程被唤醒，新的连接才能进入Executor执行。
acceptCount 实际上是Bind Socket时候传递的backlog值，在linux平台下含义是已经建立连接还没有被应用获取的连接队列最大长度。此时，如果请求个数达到了acceptCount，新进的请求将抛出refuse connection.
maxConnections:
顾名思义，即Tomcat允许的同时存在的最大连接数。默认BIO模式下，这个数值等于maxThreads，即最大线程数。超过这个值后，acceptor线程被Block。新进入的连接将由acceptCount控制。当当前连接数小于这个数值时，acceptor线程被唤醒，新的连接才能进入Executor执行。
maxThreads：
Worker线程的最大值。每当一个请求进来时，如果当前线程数小于这个值，则创建新的线程。如果大于这个值，则查找空闲线程。如果没有空闲线程，则被Block住。
Worker线程的最大值。每当一个请求进来时，如果当前线程数小于这个值，则创建新的线程。如果大于这个值，则查找空闲线程。如果没有空闲线程，则被Block住。
executor：
JDK缺省的ThreadPoolExecutor的逻辑：
如果线程数小于coreThreadSize, 优先建立新线程。
如果线程数大于coreThreadSize小于maxThreadSize，将请求入队列等待。
队列满的时候，才扩充线程数直到maxThreadSize.
当队列满，同时线程数大于maxThreadSize时，抛出异常。
Tomcat对JDK的ThreadPoolExecutor默认行为做了修改。使用继承自无界队列的LinkedBlockingQueue的TaskQueue，并改写了其入队策略，使得tomcat的Executor具有以下特性。
只要线程不足，并且小于maxThreads, 优先建立新线程。而不是超过coreSize，先入队列。
Executor如果发生reject，则将任务继续加入队列。而默认队列的size是Integer.MAX_VALUE，因此不会Reject.
在配置中，Executor可以单独配置，并被整个Tomcat共享。如果不配置，则Connector组件将使用自己默认的实现。
JDK缺省的ThreadPoolExecutor的逻辑：
如果线程数小于coreThreadSize, 优先建立新线程。
如果线程数大于coreThreadSize小于maxThreadSize，将请求入队列等待。
队列满的时候，才扩充线程数直到maxThreadSize.
当队列满，同时线程数大于maxThreadSize时，抛出异常。
Tomcat对JDK的ThreadPoolExecutor默认行为做了修改。使用继承自无界队列的LinkedBlockingQueue的TaskQueue，并改写了其入队策略，使得tomcat的Executor具有以下特性。
只要线程不足，并且小于maxThreads, 优先建立新线程。而不是超过coreSize，先入队列。
Executor如果发生reject，则将任务继续加入队列。而默认队列的size是Integer.MAX_VALUE，因此不会Reject.
在配置中，Executor可以单独配置，并被整个Tomcat共享。如果不配置，则Connector组件将使用自己默认的实现。
4.io模式优化
bio模式协议：HTTP1.1（阻塞io）
tomcat6及以前版本默认配置即可
nio模式协议：org.apache.cotyote.http11.Http11NioProtocol（非阻塞io）
tomcat7版本默认配置即可。tomcat6配置如下：
<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
connectionTimeout="20000"
redirectPort="8543" />
connectionTimeout="20000"
redirectPort="8543" />
nio2模式协议：org.apache.cotyote.http11.Http11Nio2Protocol（非阻塞io）
apr模式协议：org.apache.coyote.http11.Http11AprProtocol（异步io）
异步io依赖于操作系统apr、native支持
1)apr下载：
yum install apr-devel openssl-devel
2)native安装：
tar -zxvf tomcat-native.tar.gz
cd tomcat-native-1.1.32-src/jni/native
cd tomcat-native-1.1.32-src/jni/native
./configure –with-apr=$HOME/APR –with-java-home=$JAVA_HOME –with-ssl=$HOME/OPENSSL –prefix=$CATALINA_HOME
make && make install
make && make install
tomcat的bin目录会自动下载native，直接解压解包编译安装。
其中$HOME/APR为APR安装路径
$JAVA_HOME为JDK安装路径。
$HOME/OPENSSL为OpenSSL的安装路径。
$CATALINA_HOME为Tomcat的安装路径。
其中$HOME/APR为APR安装路径
$JAVA_HOME为JDK安装路径。
$HOME/OPENSSL为OpenSSL的安装路径。
$CATALINA_HOME为Tomcat的安装路径。
具体参考《tomcat架构解析》
bio协议模式，适用于简单流程
nio协议模式，适用于后台耗时的请求的操作
ARP模式：tomcat以jni方式调用apache http服务器的核心动态链接库来处理文件或网络传输操作
在产品环境中，特别是直接使用Tomcat做WEB服务器的时候，应该使用Tomcat Native来提高其性能.如果不配APR，基本上300个线程狠快就会用满，以后的请求就只好等待.但是配上APR之后，并发的线程数量明显下降，从原来的300可能会马上下降到只有几十，新的请求会毫无阻塞的进来.
在局域网环境测，就算是400个并发，也是一瞬间就处理/传输完毕，但是在真实的Internet环境下，页面处理时间只占0.1%都不到，绝大部分时间都用来页面传输.如果不用APR，一个线程同一时间只能处理一个用户，势必会造成阻塞。所以生产环境下用apr是非常必要的
在局域网环境测，就算是400个并发，也是一瞬间就处理/传输完毕，但是在真实的Internet环境下，页面处理时间只占0.1%都不到，绝大部分时间都用来页面传输.如果不用APR，一个线程同一时间只能处理一个用户，势必会造成阻塞。所以生产环境下用apr是非常必要的
5.jvm参数优化
Tomcat 启动命令行中的优化参数，就是 JVM 的优化 。Tomcat 首先跑在 JVM 之上的，因为它的启动其实也只是一个 java 命令行，首先我们需要对这个 JAVA 的启动命令行进行调优。不管是 YGC 还是 Full GC，GC 过程中都会对导致程序运行中中断，正确的选择不同的 GC 策略，调整 JVM、GC 的参数，可以极大的减少由于 GC 工作，而导致的程序运行中断方面的问题，进而适当的提高 Java 程序的工作效率。但是调整 GC 是一个极为复杂的过程，由于各个程序具备不同的特点，如：web 和 GUI 程序就有很大区别（Web可以适当的停顿，但GUI停顿是客户无法接受的），而且由于跑在各个机器上的配置不同（主要 cup 个数，内存不同），所以使用的 GC 种类也会不同。
JVM 常用参数：
32 位系统下 JVM 对内存的限制：不能突破 2GB ，那么这时你的 Tomcat 要优化，就要讲究点技巧了，而在 64 位操作系统上无论是系统内存还是 JVM 都没有受到 2GB 这样的限制。针对于 JMX 远程监控也是在这里设置，以下为 64 位系统环境下的配置，内存加入的参数如下：
CATALINA_OPTS="
-server
-Xms6000M
-Xmx6000M
-Xss512k
-XX:NewSize=2250M
-XX:MaxNewSize=2250M
-XX:PermSize=128M
-XX:MaxPermSize=256M
-XX:+AggressiveOpts
-XX:+UseBiasedLocking
-XX:+DisableExplicitGC
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:MaxTenuringThreshold=31
-XX:+CMSParallelRemarkEnabled
-XX:+UseCMSCompactAtFullCollection
-XX:LargePageSizeInBytes=128m
-XX:+UseFastAccessorMethods
-XX:+UseCMSInitiatingOccupancyOnly
-Duser.timezone=Asia/Shanghai
-Djava.awt.headless=true"
JVM 常用参数：
32 位系统下 JVM 对内存的限制：不能突破 2GB ，那么这时你的 Tomcat 要优化，就要讲究点技巧了，而在 64 位操作系统上无论是系统内存还是 JVM 都没有受到 2GB 这样的限制。针对于 JMX 远程监控也是在这里设置，以下为 64 位系统环境下的配置，内存加入的参数如下：
CATALINA_OPTS="
-server
-Xms6000M
-Xmx6000M
-Xss512k
-XX:NewSize=2250M
-XX:MaxNewSize=2250M
-XX:PermSize=128M
-XX:MaxPermSize=256M
-XX:+AggressiveOpts
-XX:+UseBiasedLocking
-XX:+DisableExplicitGC
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:MaxTenuringThreshold=31
-XX:+CMSParallelRemarkEnabled
-XX:+UseCMSCompactAtFullCollection
-XX:LargePageSizeInBytes=128m
-XX:+UseFastAccessorMethods
-XX:+UseCMSInitiatingOccupancyOnly
-Duser.timezone=Asia/Shanghai
-Djava.awt.headless=true"
JVM 常用参数详解：
-server：一定要作为第一个参数，在 多个 CPU 时性能佳，还有一种叫 -client 的模式，特点是启动速度比较快，但运行时性能和内存管理效率不高，通常用于客户端应用程序或开发调试，在 32 位环境下直接运行 Java 程序默认启用该模式。Server 模式的特点是启动速度比较慢，但运行时性能和内存管理效率很高，适用于生产环境，在具有 64 位能力的 JDK 环境下默认启用该模式，可以不配置该参数。
-Xms：表示 Java 初始化堆的大小， -Xms 与-Xmx 设成一样的值，避免 JVM 反复重新申请内存，导致性能大起大落，默认值为物理内存的 1/64，默认（MinHeapFreeRatio参数可以调整）空余堆内存小于 40% 时，JVM 就会增大堆直到 -Xmx 的最大限制。
-Xmx：表示最大 Java 堆大小， 当应用程序需要的内存超出堆的最大值时虚拟机就会提示内存溢出，并且导致应用服务崩溃，因此一般建议堆的最大值设置为可用内存的最大值的80%。如何知道我的 JVM 能够使用最大值，使用 java -Xmx512M -version 命令来进行测试，然后逐渐的增大 512 的值,如果执行正常就表示指定的内存大小可用，否则会打印错误信息，默认值为物理内存的 1/4，默认（MinHeapFreeRatio参数可以调整）空余堆内存大于 70% 时，JVM 会减少堆直到-Xms 的最小限制。
-Xss：表示每个
Java 线程堆栈大小，
JDK 5.0 以后每个线程堆栈大小为 1M，以前每个线程堆栈大小为 256K。根据应用的线程所需内存大小进行调整，在相同物理内存下，减小这个值能生成更多的线程，但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在 3000~5000 左右。一般小的应用， 如果栈不是很深， 应该是128k 够用的，大的应用建议使用 256k 或 512K，一般不易设置超过 1M，要不然容易出现out ofmemory。这个选项对性能影响比较大，需要严格的测试。
-XX:NewSize：设置
新生代内存大小。
-XX:MaxNewSize：设置
最大新生代新生代内存大小
-XX:PermSize：设置
持久代内存大小
-XX:MaxPermSize：设置
最大值持久代内存大小，永久代不属于堆内存，堆内存只包含新生代和老年代。
-XX:+AggressiveOpts：作用如其名（aggressive），启用这个参数，则
每当 JDK 版本升级时，你的 JVM 都会使用最新加入的优化技术（如果有的话）。
-XX:+UseBiasedLocking：启用一个优化了的线程锁，我们知道在我们的appserver，
每个http请求就是一个线程，有的请求短有的请求长，就会有请求排队的现象，甚至还会出现线程阻塞，
这个优化了的线程锁使得你的appserver内对线程处理自动进行最优调配。
-XX:+DisableExplicitGC：在 程序代码中不允许有显示的调用“System.gc()”。每次在到操作结束时手动调用 System.gc() 一下，付出的代价就是系统响应时间严重降低，就和关于 Xms，Xmx 里的解释的原理一样，这样去调用 GC 导致系统的 JVM 大起大落。
-XX:+UseConcMarkSweepGC：
设置年老代为并发收集，即 CMS gc，这一特性只有 jdk1.5
后续版本才具有的功能，它使用的是 gc 估算触发和 heap 占用触发。我们知道频频繁的 GC 会造面 JVM
的大起大落从而影响到系统的效率，因此使用了 CMS GC 后可以在 GC 次数增多的情况下，每次 GC 的响应时间却很短，比如说使用了 CMS
GC 后经过 jprofiler 的观察，GC 被触发次数非常多，而每次 GC 耗时仅为几毫秒。
后续版本才具有的功能，它使用的是 gc 估算触发和 heap 占用触发。我们知道频频繁的 GC 会造面 JVM
的大起大落从而影响到系统的效率，因此使用了 CMS GC 后可以在 GC 次数增多的情况下，每次 GC 的响应时间却很短，比如说使用了 CMS
GC 后经过 jprofiler 的观察，GC 被触发次数非常多，而每次 GC 耗时仅为几毫秒。
-XX:+UseParNewGC：对
新生代采用多线程并行回收，这样收得快，注意最新的 JVM 版本，当使用 -XX:+UseConcMarkSweepGC 时，-XX:UseParNewGC 会自动开启。因此，如果年轻代的并行 GC 不想开启，可以通过设置 -XX：-UseParNewGC 来关掉。
-XX:MaxTenuringThreshold：设置
垃圾最大年龄。如果
设置为0的话，则新生代对象不经过 Survivor 区，直接进入老年代。对于老年代比较多的应用（需要大量常驻内存的应用），可以提高效率。
如果将此值设置为一 个较大值，则新生代对象会在 Survivor 区进行多次复制，这样可以增加对象在新生代的存活时间，增加在新生代即被回收的概率，减少Full GC的频率，这样做可以在某种程度上提高服务稳定性。该参数只有在串行 GC 时才有效，这个值的设置是根据本地的 jprofiler 监控后得到的一个理想的值，不能一概而论原搬照抄。
-XX:+CMSParallelRemarkEnabled：在使用 UseParNewGC 的情况下，尽量减少 mark 的时间。
-XX:+UseCMSCompactAtFullCollection：在使用 concurrent gc 的情况下，防止 memoryfragmention，对 live object 进行整理，使 memory 碎片减少。
-XX:LargePageSizeInBytes：指定 Java heap 的分页页面大小，内存页的大小不可设置过大， 会影响 Perm 的大小。
-XX:+UseFastAccessorMethods：使用 get，set 方法转成本地代码，原始类型的快速优化。
-XX:+UseCMSInitiatingOccupancyOnly：只有在 oldgeneration 在使用了初始化的比例后 concurrent collector 启动收集。
-Duser.timezone=Asia/Shanghai：设置用户所在时区。
-Djava.awt.headless=true：这个参数一般我们都是放在最后使用的，这全参数的作用是这样的，有时我们会在我们的 J2EE 工程中使用一些图表工具如：jfreechart，用于在 web 网页输出 GIF/JPG 等流，在 winodws 环境下，一般我们的 app server 在输出图形时不会碰到什么问题，但是在linux/unix 环境下经常会碰到一个 exception 导致你在 winodws 开发环境下图片显示的好好可是在 linux/unix 下却显示不出来，因此加上这个参数以免避这样的情况出现。
-Xmn：
新生代的内存空间大小，注意：此处的大小是（
eden+ 2 survivor space)。与 jmap -heap 中显示的 New gen 是不同的。整个
堆大小 = 新生代大小 + 老生代大小 + 永久代大小。在
保证堆大小不变的情况下，增大新生代后，将会减小老生代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的 3/8。
-XX:CMSInitiatingOccupancyFraction：
当堆满之后，并行收集器便开始进行垃圾收集，例如，当没有足够的空间来容纳新分配或提升的对象。对于 CMS 收集器，长时间等待是不可取的，因为在并发垃圾收集期间应用持续在运行（并且分配对象）。因此，为了在应用程序使用完内存之前完成垃圾收集周期，CMS 收集器要比并行收集器更先启动。因为不同的应用会有不同对象分配模式，JVM 会收集实际的对象分配（和释放）的运行时数据，并且分析这些数据，来决定什么时候启动一次 CMS 垃圾收集周期。这个参数设置有很大技巧，基本上满足(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100 >= Xmn 就不会出现 promotion failed。例如在应用中 Xmx 是6000，Xmn 是 512，那么 Xmx-Xmn 是 5488M，也就是老年代有 5488M，CMSInitiatingOccupancyFraction=90 说明老年代到 90% 满的时候开始执行对老年代的并发垃圾回收（CMS），这时还 剩 10% 的空间是 5488*10% = 548M，所以即使 Xmn（也就是新生代共512M）里所有对象都搬到老年代里，548M 的空间也足够了，所以只要满足上面的公式，就不会出现垃圾回收时的 promotion failed，因此这个参数的设置必须与 Xmn 关联在一起。
-XX:+CMSIncrementalMode：该标志将开启 CMS 收集器的增量模式。增量模式经常暂停 CMS 过程，以便对应用程序线程作出完全的让步。因此，收集器将花更长的时间完成整个收集周期。因此，只有通过测试后发现正常 CMS 周期对应用程序线程干扰太大时，才应该使用增量模式。由于现代服务器有足够的处理器来适应并发的垃圾收集，所以这种情况发生得很少，用于但 CPU情况。
-XX:NewRatio：
年轻代（包括 Eden 和两个 Survivor 区）与年老代的比值（除去持久代），-XX:NewRatio=4 表示年轻代与年老代所占比值为 1:4，年轻代占整个堆栈的 1/5，Xms=Xmx 并且设置了 Xmn 的情况下，该参数不需要进行设置。
-XX:SurvivorRatio：
Eden 区与 Survivor 区的大小比值，设置为 8，表示 2 个 Survivor 区（JVM 堆内存年轻代中默认有 2 个大小相等的 Survivor 区）与 1 个 Eden 区的比值为 2:8，即 1 个 Survivor 区占整个年轻代大小的 1/10。
-XX:+UseSerialGC：
设置串行收集器。
-XX:+UseParallelGC：
设置为并行收集器。此配置仅对年轻代有效。即年轻代使用并行收集，而年老代仍使用串行收集。
-XX:+UseParallelOldGC：
配置年老代垃圾收集方式为并行收集，JDK6.0 开始支持对年老代并行收集。
-XX:ConcGCThreads：早期 JVM 版本也叫-XX:ParallelCMSThreads，定义并发 CMS 过程运行时的线程数。比如 value=4 意味着 CMS 周期的所有阶段都以 4 个线程来执行。尽管更多的线程会加快并发 CMS 过程，但其也会带来额外的同步开销。因此，对于特定的应用程序，应该通过测试来判断增加 CMS 线程数是否真的能够带来性能的提升。如果还标志未设置，JVM 会根据并行收集器中的 -XX:ParallelGCThreads 参数的值来计算出默认的并行 CMS 线程数。
-XX:ParallelGCThreads：配置并行收集器的线程数，即：同时有多少个线程一起进行垃圾回收，此值建议配置与 CPU 数目相等。
-XX:OldSize：设置 JVM 启动分配的老年代内存大小，类似于新生代内存的初始大小 -XX:NewSize。
以上就是一些常用的配置参数，有些参数是可以被替代的，配置思路需要考虑的是 Java 提供的垃圾回收机制。 虚拟机的堆大小决定了虚拟机花费在收集垃圾上的时间和频度。收集垃圾能够接受的速度和应用有关，应该通过分析实际的垃圾收集的时间和频率来调整。假如堆的大小很大，那么完全垃圾收集就会很慢，但是频度会降低。假如您把堆的大小和内存的需要一致，完全收集就很快，但是会更加频繁。调整堆大小的的目的是最小化垃圾收集的时间，以在特定的时间内最大化处理客户的请求。在基准测试的时候，为确保最好的性能，要把堆的大小设大，确保垃圾收集不在整个基准测试的过程中出现。
假如系统花费很多的时间收集垃圾，请减小堆大小。一次完全的垃圾收集应该不超过 3-5 秒。假如垃圾收集成为瓶颈，那么需要指定代的大小，检查垃圾收集的周详输出，研究垃圾收集参数对性能的影响。当增加处理器时，记得增加内存，因为分配能够并行进行，而垃圾收集不是并行的。
以上就是一些常用的配置参数，有些参数是可以被替代的，配置思路需要考虑的是 Java 提供的垃圾回收机制。 虚拟机的堆大小决定了虚拟机花费在收集垃圾上的时间和频度。收集垃圾能够接受的速度和应用有关，应该通过分析实际的垃圾收集的时间和频率来调整。假如堆的大小很大，那么完全垃圾收集就会很慢，但是频度会降低。假如您把堆的大小和内存的需要一致，完全收集就很快，但是会更加频繁。调整堆大小的的目的是最小化垃圾收集的时间，以在特定的时间内最大化处理客户的请求。在基准测试的时候，为确保最好的性能，要把堆的大小设大，确保垃圾收集不在整个基准测试的过程中出现。
假如系统花费很多的时间收集垃圾，请减小堆大小。一次完全的垃圾收集应该不超过 3-5 秒。假如垃圾收集成为瓶颈，那么需要指定代的大小，检查垃圾收集的周详输出，研究垃圾收集参数对性能的影响。当增加处理器时，记得增加内存，因为分配能够并行进行，而垃圾收集不是并行的。
配置方式：
window下， 在catalina.bat最前面：
set JAVA_OPTS=-XX:PermSize=64M -XX:MaxPermSize=128m -Xms512m -Xmx1024m;-Duser.timezone=GMT+08;
一定加在catalina.bat最前面。
linux下，在catalina.sh最前面增加：
JAVA_OPTS="-XX:PermSize=64M -XX:MaxPermSize=128m -Xms512m -Xmx1024m -Duser.timezone=Asia/Shanghai"
set JAVA_OPTS=-XX:PermSize=64M -XX:MaxPermSize=128m -Xms512m -Xmx1024m;-Duser.timezone=GMT+08;
一定加在catalina.bat最前面。
linux下，在catalina.sh最前面增加：
JAVA_OPTS="-XX:PermSize=64M -XX:MaxPermSize=128m -Xms512m -Xmx1024m -Duser.timezone=Asia/Shanghai"
优化目的：
上述这样的配置，基本上可以达到：
系统响应时间增快；
JVM回收速度增快同时又不影响系统的响应率；
JVM内存最大化利用；
线程阻塞情况最小化。
上述这样的配置，基本上可以达到：
系统响应时间增快；
JVM回收速度增快同时又不影响系统的响应率；
JVM内存最大化利用；
线程阻塞情况最小化。
6.常见java内存溢出
java.lang.OutOfMemoryError: Java heap space —-
JVM Heap（堆）溢出：
JVM 在启动的时候会自动设置 JVM Heap 的值，其初始空间（即-Xms）是物理内存的1/64，最大空间（-Xmx）不可超过物理内存。可以利用 JVM提供的 -Xmn -Xms -Xmx 等选项可进行设置。Heap 的大小是 Young Generation 和 Tenured Generaion 之和。在 JVM 中如果 98％ 的时间是用于 GC，且可用的 Heap size 不足 2％ 的时候将抛出此异常信息。
解决方法：手动设置 JVM Heap（堆）的大小。
JVM 在启动的时候会自动设置 JVM Heap 的值，其初始空间（即-Xms）是物理内存的1/64，最大空间（-Xmx）不可超过物理内存。可以利用 JVM提供的 -Xmn -Xms -Xmx 等选项可进行设置。Heap 的大小是 Young Generation 和 Tenured Generaion 之和。在 JVM 中如果 98％ 的时间是用于 GC，且可用的 Heap size 不足 2％ 的时候将抛出此异常信息。
解决方法：手动设置 JVM Heap（堆）的大小。
java.lang.OutOfMemoryError: PermGen space —-
PermGen space溢出：
PermGen space 的全称是 Permanent Generation space，是指内存的永久保存区域。为什么会内存溢出，这是由于这块内存主要是被 JVM 存放Class 和 Meta 信息的，Class 在被 Load 的时候被放入 PermGen space 区域，它和存放 Instance 的 Heap 区域不同，sun 的 GC 不会在主程序运行期对 PermGen space 进行清理，所以如果你的 APP 会载入很多 CLASS 的话，就很可能出现 PermGen space 溢出。
解决方法： 手动设置 MaxPermSize 大小
java.lang.StackOverflowError —- 栈溢出：
栈溢出了，JVM 依然是采用栈式的虚拟机，这个和 C 与 Pascal 都是一样的。函数的调用过程都体现在堆栈和退栈上了。调用构造函数的 “层”太多了，以致于把栈区溢出了。通常来讲，一般栈区远远小于堆区的，因为函数调用过程往往不会多于上千层，而即便每个函数调用需要 1K 的空间（这个大约相当于在一个 C 函数内声明了 256 个 int 类型的变量），那么栈区也不过是需要 1MB 的空间。通常栈的大小是 1－2MB 的。
通常递归也不要递归的层次过多，很容易溢出。
解决方法：修改程序。
PermGen space 的全称是 Permanent Generation space，是指内存的永久保存区域。为什么会内存溢出，这是由于这块内存主要是被 JVM 存放Class 和 Meta 信息的，Class 在被 Load 的时候被放入 PermGen space 区域，它和存放 Instance 的 Heap 区域不同，sun 的 GC 不会在主程序运行期对 PermGen space 进行清理，所以如果你的 APP 会载入很多 CLASS 的话，就很可能出现 PermGen space 溢出。
解决方法： 手动设置 MaxPermSize 大小
java.lang.StackOverflowError —- 栈溢出：
栈溢出了，JVM 依然是采用栈式的虚拟机，这个和 C 与 Pascal 都是一样的。函数的调用过程都体现在堆栈和退栈上了。调用构造函数的 “层”太多了，以致于把栈区溢出了。通常来讲，一般栈区远远小于堆区的，因为函数调用过程往往不会多于上千层，而即便每个函数调用需要 1K 的空间（这个大约相当于在一个 C 函数内声明了 256 个 int 类型的变量），那么栈区也不过是需要 1MB 的空间。通常栈的大小是 1－2MB 的。
通常递归也不要递归的层次过多，很容易溢出。
解决方法：修改程序。