配置tomcat 内存 及项目访问路径

一 以下是关于设置项目的默认访问路径

  1> 先将 tomcat/web.xml 中<welcome-file-list>里的值删除
  2> 将项目放在任意一个盘符下，建议不要使用中文路径 （注意：不要将项目放在tomcat/webapps下,防止通过绝对路径可以访问到项目）
  3>在server.xml <Host>..</Host>标记下配置以下属性：
<Context path="" docBase="G:\projectName" reloadable="true" privileged="true" debug="0"></Context>
  4>在server.xml中<port>...</port>标记下修改tomcat默认端口为80
  这样就可以直接通过IP访问到项目了

二 如果配置tomcat内存 防止项目报内存错误  设置catalina.bat文件
     echo Using CATALINA_BASE:   "%CATALINA_BASE%"
    echo Using CATALINA_HOME:   "%CATALINA_HOME%"
    echo Using CATALINA_TMPDIR: "%CATALINA_TMPDIR%"
在以上这三个标签下配置以下属性及可
   JAVA_OPTS=%JAVA_OPTS% -server –Xms8000m -Xmx8000m -XX:PermSize=4000m -XX:MaxPermSize=6000m


   以下是关于tomcat内存设置的详细配置说明 （网址：http://sinckyzhang.blog.sohu.com/149067215.html）

   核心内容如下：
    【JVM参数实例一】JVM PermGen溢出：

java.lang.OutOfMemoryError  PermGen space

    由于GC不会在主程序运行期对PermGen进行清理，所以如果你的应用中有很多CLASS的话，就很可能出现PermGen space错误，这种错误常见在WEB服务器对JSP进行预编译的时候发生。如果你的WEB APP下都用了大量的第三方JAR包, 其大小超过了JVM默认的大小(4M)那么就会产生此错误信息了。

    解决方法： 手动设置MaxPermSize大小。修改TOMCAT_HOME/bin/catalina.bat，在echo Using CATALINA_base:%CATALINA_base%上面加入以下行：

JAVA_OPTS=%JAVA_OPTS% -server -XX:PermSize=64M -XX:MaxPermSize=128m

建议：将相同的第三方jar文件移置到tomcat/shared/lib目录下，这样可以达到减少jar 文档重复占用内存的目的。

【JVM参数实例二】JVM Heap溢出：

java.lang.OutOfMemoryError: Java heap space

     JVM Heap堆的设置是指java程序运行过程中JVM可以调配使用的内存空间。JVM在启动的时候会自动设置Heap size的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。提示：在JVM中如果98％的时间是用于GC且可用的Heap大小不足2％的时候将抛出此异常信息。Heap最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。
    解决方法：手动设置Heap size，例如：

JAVA_OPTS=%JAVA_OPTS% -server -Xms800m -Xmx800m

    但是有的时候可能这样的设置还会不生效，例如当JVM加载大量Class类时，永久域中的对象急剧增加，从而

使JVM不断调整永久域大小。为了避免自动调整，可以使用前面的参数结合设置，如：

JAVA_OPTS=%JAVA_OPTS% -server -Xms800m -Xmx800m -XX:PermSize=64m -XX:MaxPermSize=128m

    基于Sun 的Java的垃圾回收机制，允许分隔内存池以包含不同时效的对象，垃圾回收循环根据时效收集与其他对象彼此独立的对象。使用其他参数，您可以单独设置内存池的大小。为了实现更好的性能，可以对包含短期存活对象的池的大小进行设置，以使该池中的对象的存活时间不会超过一个垃圾回收循环。新生成的池的大小由 NewSize和MaxNewSize参数确定。如：

JAVA_OPTS=%JAVA_OPTS% -server -Xms800m -Xmx800m  -XX:PermSize=64m -XX:MaxPermSize=128m -XX:NewSize=8m -XX:MaxNewSize=16m

【JVM参数实例三】垃圾回收时promotion failed:

    这个问题一般由两种原因引起，第一个原因是Survivor空间不够，里面的对象还不应该被移动到Old区，但New区又有很多对象需要放入Survivor；第二个原因是Old区没有足够的空间接纳来自New区的对象；这两种情况都会转向Full GC，造成系统卡住时间较长。第一个原因可以通过去掉救助空间解决，设置-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0即可，第二个原因可以设置CMSInitiatingOccupancyFraction为某个值（假设70），这样Old区的70%时就开始执行CMS，Old区有足够的空间接纳来自New的对象。但是不管怎样，PermGen还是会逐渐变满，所以隔三差五重起java服务器是必要的。需要注意的是，Old区用的是并发回收，可以设置New区小一点，Old区大些，可以减少系统的卡住。

    解决方法：

$JAVA_ARGS .= " -Dresin.home=$SERVER_ROOT -server -Xms6000M -Xmx6000M -Xmn500M -XX:PermSize=500M -XX:MaxPermSize=500M -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0 -Xnoclassgc -XX:+DisableExplicitGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:-CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=90 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log"

-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0 就是去掉了救助空间
-Xnoclassgc 禁用类垃圾回收，性能会高一点
-XX:+DisableExplicitGC 禁止System.gc()，免得程序员误调用gc方法影响性能
-XX:+UseParNewGC 对New采用多线程并行回收，这样收得快
带CMS参数的都是和并发回收相关的:
CMSInitiatingOccupancyFraction，这个参数设置有很大技巧，基本上满足(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn 就不会出现promotion failed。在这里Xmx是6000，Xmn是500，那么Xmx-Xmn是5500m，也就是Old有5500m，CMSInitiatingOccupancyFraction=90说明Old到90%满的时候开始执行对Old区的并发垃圾回收（CMS），这时还剩10%的空间是5500*10%=550m，所以即使Xmn（也就是New共500m）里所有对象都搬到Old里，550兆的空间也足够了，所以只要满足上面的公式，就不会出现垃圾回收时的promotion failed。
SoftRefLRUPolicyMSPerMB这个参数是softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap。

    但是，这种设置方法因为没有用到Survivor，所以Old区容易满，CMS执行会比较频繁。建议还是用Survivor并把加大，这样也不会有promotion failed错误。配置上32位和64位不一样，64位系统只要配置MaxTenuringThreshold参数，CMS还是有暂停。为了解决暂停问题和promotion failed问题，最后我设置-XX:SurvivorRatio=1 ，并把MaxTenuringThreshold去掉，这样即没有暂停又不会有promotoin failed，而且更重要的是，Old区和PermGen上升非常慢（因为好多对象到不了年老代就被回收了），所以CMS执行频率非常低，好几个小时才执行一次，这样，服务器都不用重启了。下面是64位的配置，系统8G内存。

-Xmx4000M -Xms4000M -Xmn600M -XX:PermSize=500M -XX:MaxPermSize=500M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log

【JVM启动参数介绍】

-Xmn  －Eden Generation的Heap大小，一般设置为Xmx的1/3或1/4

-Xmx  －设置JVM Heap大小最大值，这里的heap = New Generation + Old Generation，但不包括PermGen

-Xms  －设置JVM Heap大小初始值

-XX:NewRatio －New/Old的大小比率

-XX:NewSize －New Generation Heap的大小

-XX:MaxNewSize －可以通过NewRatio和-Xmx计算得到

-XX:SurvivorRatio －Eden/Survivor Space大小比率

-XX:PermSize －PermGen的初始值

-XX:MaxPermSize －PermGen最大值

-Xss： －设置每个线程的Stack大小

-XX:+UseParNewGC  －表示多CPU下缩短Minor GC的时间

-XX:+UseParallelGC  －设置后可以使用并行清除收集器【多CPU】

-XX:+ParallelGCThreads  －可用来增加并行度【多CPU】

-XX:+AggressiveOpts  －是否激活最近的试验性性能调整

-XX:-Xnoclassgc  －是否允许类垃圾收集，默认设置是允许类 GC

-XX:+UseLargePages  －是否支持大页面堆

-XX:+UseFastAccessorMethods  －在指定了这个参数后，JDK会将所有的get/set方法都转为本地代码

-XX:+UseConcMarkSweepGC  －缩短major收集的时间，此选项在Heap比较大而且Full GC时间较长的情况下使用更合适

    另外，JVM的一些参数可以输出有效的日志文件：

-verbose:gc  －输出一些gc信息

-XX:+PrintGCDetails  －输出gc详细信息

-XX:+PrintGCTimeStamps  －包含时间戳信息

-XX:+PrintHeapAtGC  －包括gc前后Heap状况

-XX:+PrintTenuringDistribution  －输出对象存活时间和Tenured Generation的其他信息

-XX:+PrintHeapUsageOverTime  －以时间戳输出heap利用率和容量信息

-Xloggc:filename  －输出gc信息到日志文件
    例如：

set JAVA_OPTS=%JAVA_OPTS% -verbose:gc -Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC

     如果输出的日志文件非常大，可以后续采用其它工具分析；或者干脆使用Jstat或Jconsole这些成熟的工具直接监控JVM的GC问题。当然，前边图示的VisualVM更是一款漂亮的、即时监控JVM GC的工具。

    下面的命令把整个堆设置成128m，New/Old比率设置成3，即New与Old比例为1：3，New Space为Heap的1/4即32M, 缺省值为NewSize=2m MaxNewSize=32m SurvivorRatio=2

java –Xms128m –Xmx128m –XX:NewRatio=3

    但是，如果JVM的堆Heap大小大于1GB，则应该使用值：-XX:newSize=640m -XX:MaxNewSize=640m -XX:SurvivorRatio=16，或者将堆的总大小的50%到60%分配给新生成的池。

【JVM性能瓶颈】

    在JAVA应用程序中，虽然不太容易出现内存泄漏的问题，因为JVM会不定期的进行垃圾回收。但是因为程序的不合理写法，也会导致一些数据不能被收集。典型的状况是在HashMap中放置大量不用的数据，而没有及时的清理。在web应用中，很多人喜欢在Session放放置状态数据，而没有清理，也是内存泄漏的一个原因。在Session中存放数据还好，因为Session终究会有过期时间，但是如果在Class的Static变量中放置数据，那就怎么样也没办法了。诊断应用中是否存在内存泄漏也有一些方法，通过分析JVM GC Log就是一个直观的方式。通过分析GC After Heap的变化趋势，如果GC After Heap稳步上升，立刻进行Full GC后，仍然不能降下来，通常就意味着存在内存泄漏了。当然也有情况是，的确有一些数据是应用程序的需求，我们要确认除了这些数据，是否还存在一些异常数据一直占据内存。可以通过JProbe的Memory Views来观察Class的对象数，在一段请求过后，如果还存在一些Class的Instance数目相当多，就可以判断这个Class可能会是问题的根源。