java内存调优
‘壹’ tomcat 性能调优
java性能优化原则:代码运算性能 内存回收 应用配置(影响java程序注意原因是垃圾回收)
代码层优化:避免过多的循环嵌套 调用和复杂逻辑
Tomcat调优主要内容
1.增加最大连接数
2.调整工作模式
3.启用gzip压缩
4.调整JVM内存大小
5.作为web服务器时 与Apache整合或Nginx
6.合理选择垃圾回收算法
7.尽量使用较新版的JDK
生产环境实例
<connector p=""
maxThreads="1000"
minSpareThreads="100"
maxSpareThreads="200"
acceptCount="900"
disableUploadTimeout="true"
connectionTimeout="20000"
URIEncoding="UTF-8"
enableLookups="false"
redirectPort="8443"
compression="on"
compressionMinSize="1024"
compressableMimeType="text/html,text/xml,text/css,text/javascript"/>
参数说明:
org.apache.coyote.http11.Http11NioProtocol：调整工作模式为Nio
maxThreads：最大线程数，默认150。增大值避免队列请求过多，导致响应缓慢。
minSpareThreads：最小空闲线程数
maxSpareThreads：最大空闲线程数，如果超过这个值，会关闭无用的线程。
acceptCount：当处理请求超过此值时，将后来请求放到队列中等待。
disableUploadTimeout：禁用上传超时时间
connectionTimeout：连接超时，单位毫秒，0代表不限制
URIEncoding：URI地址编码使用UTF-8
enableLookups：关闭dns解析，提高响应时间
compression：启用压缩功能
compressionMinSize：最小压缩大小，单位Byte
compressableMimeType：压缩的文件类型
Tomcat的三种工作模式: Bio、Nio和Apr 工作原理分别为
Bio(Blocking I/O):默认工作模式 阻塞式I/O操作 没有任何优化技术处理 性能比较低
Nio(New I/O or Non-Blocking):非阻塞式I/O操作 有BIO更好的并发处理性能
Apr(apache portable runtime,apache可移植运行库):首选工作模式 主要为上层的应用程序提供一个可以跨越多操作系统平台使用的底层支持接口库
Tomcat利用基于APR库Tomcat-native来实现操作系统级别控制 提供一种优化技术和非阻塞式I/O操作 大大提高并发处理能力
但是需要安装APR和Tomcat-native库
Java性能问题主要来自于jvm jvm GC也比较复杂
1、jvm内存划分为年轻代(Young Generation)、年老代 Old Generation)、永久代(Permanent Generation)
2、年轻代又分为Eden和Survivor区。Survivor区由FromSpace和ToSpace组成。Eden区占大容量,Survivor两个区占小容量,默认8:2
3、堆内存Heap=年轻代+年老代 非堆内存=永久代
4、堆内存用途:存放的是对象 垃圾收集器就是收集这些对象的 然后根据GC算法回收
5、非堆内存用途:JVM本身使用 存放一些类型 方法 常量 属性等
6、年轻代:新生成的对象首选放到年轻代的E区中 当E区满时 经过GC后 还存活的对象被复制到Survivor区的FromSpace中 如果survivor区满
会再被复制到survivor区的ToSpace区 如果还有存活的对象 会再被复制到老年代
7、老年代:在年轻代中经过GC后还存活的对象会被复制到老年代中 当老年代空间不足时 jvm会对老年代进行完全的垃圾回收(Full GC)
如果GC后 还是无法存放从survivor区复制过来的对象 就会出现OOM
8、永久代:也称为方法区 存放静态类型数据 比如类 方法 属性等
垃圾回收算法
1、标记 清除
2、复制
3、标记 整理
垃圾收集器
单线程/多线程收集器
GMS收集器
JAVA_OPTS="-server -Xms1024m -Xmx1536m -XX:PermSize=256m -XX:MaxPermSize=512m -XX:+UseConcMarkSweepGC -XX:+UseParallelGCThreads=8 XX:=80 -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:-PrintGC -XX:-PrintGCDetails -XX:-PrintGCTimeStamps -Xloggc:../logs/gc.log"
参数 描述
-Xms 堆内存初始大小 单位M、G
-Xmx 堆内存最大允许大小 一般不要大于物理内存的80%
-XX:PermSize 非堆内存初始大小 一般应用设置初始化200M 最大1024M就够了
-XX:MaxPermSize 非堆内存最大允许值
-XX:+UseParallelGCThreads=8 并行收集器线程数 同时有多少个线程进行垃圾回收 一般与CPU数量相等
-XX:+UseParalle101dGC 指定老年代为并行收集
-XX:+UseConcMarkSweepGC CSM收集器
-XX:+ 开启内存空间压缩和整理 防止过多内存碎片
-XX:CMSFullGCsBeforeCompaction=0 表示多少次Full GC后开始压缩和整理 0表示每次Full GC后立即执行压缩和整理
-XX:=80% 表示老年代内存空间使用80%时开始执行CMS收集 防止过多的Full GC
注意:不是jvm内存设置越大越好 具体还是根据项目对象实际占内存大小而定 可以通过java自带的分析工具来查看
如果设置过大 会增加回收实际 从而增加暂停应用时间
gzip压缩作用:节省服务器流量和提高网站访问速度 客户端请求服务器资源后 服务器将资源文件压缩 再返回给客户端 有客户端的浏览器负责压缩并浏览
Apache和Tomcat结合
由于Tomcat处理静态文件能力远远不足Apache 所有用Apache处理静态文件 Tomcat负责处理jsp
session会话的保持
TomcatSessionID持久化三种方法
session粘性:通过浏览器cookie绑定sessionID 通过sticky模式将同一session请求分片到同一Tomcat上
session复制:tomcat通过广播形式将session同步到其它Tomcat节点 并且Linux下要手动开启开放广播地址 不宜后端节点过多
session保持数据库(memcache redis):将sessionID保存在共享的数据库中
OOM异常的几个原因
老年代内存不足:java.lang.OutOfMemoryError:Javaheapspace
永久代内存不足:java.lang.OutOfMemoryError:PermGenspace
代码bug 占用内存无法及时回收
‘贰’ Java软件工程师主要学习哪些课程
第一阶段，Java SE基础：
Java环境搭建、Java流程控制语句-for循环、switch选择判断、循环嵌套、数组拷贝、多维数组、final关键字、构造函数的调用、类的访问权限和路径、面向对象高级特性、Java异常处理、Set，Map，List接口及接口实现类、Java线程、同步阻塞、JavaIO流、文件的操作，复制，读写，删除等。第二阶段，JavaWeb：Mysql安装、管理、创建数据库、MySQL
UPDATE 查询、Mysql高级操作、JDBC、JDBC数据库连接操作，JDBC动态Sql处理、Servlet3.0
网页重定向、Servlet3.0 新增的注解支持、AJAX、responseText属性详解等。第三阶段，Java高级框架-SSH：Struts2异常处理、Struts2+Log4j集成、Struts2和JSON实例、Hibernate5、Hibernate集合映射、Hibernate组件映射、Spring4.0、SpringAOP
+ AspectJ框架、Spring 与其它Web框架集成、Spring Hibernate支持等。第四阶段，Java高级框架-SSM：SpringMVC、Spring MVC生成JSON数据、MyBatis、MyBatis 环境配置及入门、Mybatis set标签、Mybatis trim标签、Shiro、Shiro快速入门教程、Shiro Web应用等。第五阶段，SpringBoot+VUE全栈框架：SpringBoot、全局异常处理、过滤器监听器、EHCache缓存、SpringBoot Quartz定时任务、Vue、Vue.js 安装、模板语法、计算属性、事件处理器、Vue.js 自定义指令、Vue.js 路由等第六阶段，特色课程：ActiveM环境搭建、生产者和消费者、消息持久化操作、RSA数字加密算法、Codebar条形码生成器、zxing二维码生成器、HighCharts统计图、Echarts统计图、网络播放器ckplayer、嵌入式网络播放器，可以浏览器和移动端随意使用第七阶段，互联网框架的高级应用1：分布式服务框架的理解，Dubbo架构设计详解及其核心要点，框架运行原理分析、SpringData数据访问、Lucene搜索引擎、Lucene的全文搜索服务器介绍、索引建立方式、Solr海量数据搜索引擎、Socket网络通信、实现RMI远程对象通讯、使用JMS消息服务、Kafka分布式消息系统、WebService与Restful
WS等第八阶段，互联网框架的高级应用2：Spring Security安全框架、实现Web应用安全控制、缓存应用与EhCache框架、OSCache与JBossCache框架、MyBatis与Hibernate缓存机制、NoSQL应用与SQL调优、MongoDB
NoSQL数据库、Redis内存数据库、实现Redis
Session共享、SQL语句的优化、实现数据库读写分离、WEB应用集群及性能优化、Maven项目管理工具、Web服务器负载均衡、实现Nginx与Tomcat集群、使用LoadRunner测试工具、性能优化之内存调优、代码优化与重构的方法等。
对java有兴趣的小伙伴们，不妨先从java入门开始！B站上有很多的java教学视频，从基础到高级的都有，还挺不错的，知识点讲的很细致，还有完整版的学习路线图。也可以自己去看看，下载学习试试。
‘叁’ java有内存溢出吗如果有是什么情况
内存溢出是指应用系统中存在无法回收的内存或使用的内存过多，最终使得程序运行要用到的内存大于虚拟机能提供的顷高最大内存。
所以我们应该明确：存在内存溢出的因不一定导致内存溢出的果。。。
1。JAVA操作文本文件为什么超过3万行就雀衡尺内存益处啊？
PrintWriter out = new PrintWriter(new BufferedWriter(new FileWriter(fileName)));
//PrintWriter out = new PrintWriter(fileName);
//FileOutputStream out = new FileOutputStream(fileName);
while (rs.next()) {
for (int j = 1; j <= totalColumn; j++) {
out.write(rs.getObject(j).toString());
out.write("\t");
}
out.write("\n");
out.flush();
}
}
我在代码中 写了 out.flush()用来刷新该流的缓冲; 可是当我的记录数超过3W时就报了内存益处的问题了，难道JAVA不能边读边写吗？还是out这个对象随着指向的fileName文件的边大占用内存也大了吗？？到底怎么来实现用JAVA写更多的数据而不内存益处呢
答案是：就在while(rs.next()) 当rs.next()时内存不断增大，而不是写流的问题，JAVA的ResultSet真是麻烦，而且ResultSet还不能clone(); 所以记得在做项目的时候，经常要设置：jdbc.setMaxRows(100*10000); //设置能容纳100万行记录-----这个就是防止内存泄露的哈------------------- 内存中加载的数据量过于庞大，如一次从数据库取出过多数据；
jdbc.setQueryTimeout(60*30); //设置超时时间是30分钟
2。java中的内存泄露的情况：长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄露，尽管短生命周期对象已经不再需要，但是因为长生命周期对象持有它的引用而导致不能被回收，这就是java中内存泄露的发生场景，通俗地说，就是程序员可能创建了一个对象，以后一直不再使用这个对象，这个对象却一直被引用，即这个对象无用但是却无法被垃圾回收器回收的拦改，这就是java中可能出现内存泄露的情况，例如，缓存系统，我们加载了一个对象放在缓存中(例如放在一个全局map对象中)，然后一直不再使用它，这个对象一直被缓存引用，但却不再被使用。
public class Stack { //长生命周期
private Object[] elements=new Object[10]; //当数组容器中没有东西时是无用的，但是无法回收~~elements是短生命周期
private int size = 0;
public void push(Object e){
ensureCapacity();
elements[size++] = e;
}
public Object pop(){
if( size == 0)
throw new EmptyStackException();
//这里还是引用了，只是指针变位置变化而已，他确实返回了那个对象，但是他却没有断开那个对象的引用，也就是说有两个地方会持有这个对象的引用，调用pop的地方，和elements中
return elements[--size];
}
private void ensureCapacity(){
if(elements.length == size){
Object[] oldElements = elements;
elements = new Object[2 * elements.length+1];
System.array(oldElements,0, elements, 0, size);
}
}
}
上面的原理应该很简单，假如堆栈加了10个元素，然后全部弹出来，虽然堆栈是空的，没有我们要的东西，但是这是个对象是无法回收的，这个才符合了内存泄露的两个条件(必要条件)：无用，无法回收。
例子1
public class Bad{
public static Stack s=Stack();
static{
s.push(new Object());
s.pop(); //这里有一个对象发生内存泄露
s.push(new Object()); //上面的对象可以被回收了，等于是自愈了，因为引用被覆盖了
}
}
因为是static，就一直存在到程序退出，但是我们也可以看到它有自愈功能，就是说如果你的Stack最多有100个对象，那么最多也就只有100个对象无法被回收其实这个应该很容易理解，Stack内部持有100个引用，最坏的情况就是他们都是无用的，因为我们一旦放新的进取，以前的引用自然消失！
内存泄露的另外一种情况：当一个对象被存储进HashSet集合中以后，就不能修改这个对象中的那些参与计算哈希值的字段了，否则，对象修改后的哈希值与最初存储进HashSet集合中时的哈希值就不同了，在这种情况下，即使在contains方法使用该对象的当前引用作为的参数去HashSet集合中检索对象，也将返回找不到对象的结果，这也会导致无法从HashSet集合中单独删除当前对象，造成内存泄露。
这是属于： 集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；
3。代码中存在死循环或循环产生过多重复的对象实体；
4。启动参数内存值设定的过小；
‘肆’ 懂JAVA的大虾们，帮帮忙,JVM不释放内存,为什么
IBM关于内存泄漏的文章：
1）http://www.ibm.com/developerworks/library/j-leaks/index.html
2）http://www.ibm.com/developerworks/cn/java/l-JavaMemoryLeak/
第一篇结尾有提到预防泄漏的方法：
a）注意集合类（比如 Hashtable 和 Vector）；尤其是声明为 static 的
b）记得移除不再需要的事件/组件监听器
c）很多类稿宴历都有引用类型的成员变量；不再需要这些成员变量引祥悉用的键搜对象时，把它们设为 null
程序没有外部调用，把程序停了，系统也不释放内存？
怎么可能？
最好代码能让大家看看。
‘伍’ 学习Java为什么需要理解它的内存机制
不懂Java的内存机制，遇到某些问题磨没李时就不知道其中的微妙原因，也写不出好的高并发安全、低内存占用的程序，也不会JVM的性能调优。理解底层原理有助于理解很多瞎迟东西实察纤现的细节。
‘陆’ jvm 内存调优用过哪些工具，jstate 做什么用的如何 mp 出当前线程状态
实例一：Waiting to lock 和 Blocked
"RMI TCP Connection(267865)-172.16.5.25" daemon prio=10 tid=0x00007fd508371000 nid=0x55ae waiting for monitor entry [0x00007fd4f8684000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.log4j.Category.callAppenders(Category.java:201)
- waiting to lock <0x00000000acf4d0c0> (a org.apache.log4j.Logger)
at org.apache.log4j.Category.forcedLog(Category.java:388)
at org.apache.log4j.Category.log(Category.java:853)
at org.apache.commons.logging.impl.Log4JLogger.warn(Log4JLogger.java:234)
at com.tuan.core.common.lang.cache.remote.SpyMemcachedClient.get(SpyMemcachedClient.java:110)
说明：
1）线程状态是 Blocked，阻塞状态。说明线程等待资源超时裂闷！
2）“ waiting to lock <0x00000000acf4d0c0>”指，线程在等待给这个 0x00000000acf4d0c0 地址上锁（英文可肆迹弯描述为：trying to obtain 0x00000000acf4d0c0 lock）。
3）在 mp 日志里查找字符串 0x00000000acf4d0c0，发现有大量线程都在等待给这个地址上锁。如果能在日志里找到谁获得了这个锁（如locked < 0x00000000acf4d0c0 >），就可以顺藤摸瓜了。
4）“waiting for monitor entry”说明此线程通过 synchronized(obj) {……} 申州告请进入了临界区，从而进入了下图1中的“Entry Set”队列，但该 obj 对应的 monitor 被其他线程拥有，所以本线程在 Entry Set 队列中等待。
5）第一行里，"RMI TCP Connection(267865)-172.16.5.25"是 Thread Name 。tid指Java Thread id。nid指native线程的id。prio是线程优先级。[0x00007fd4f8684000]是线程栈起始地址。
实例二：Waiting on condition 和 TIMED_WAITING
"RMI TCP Connection(idle)" daemon prio=10 tid=0x00007fd50834e800 nid=0x56b2 waiting on condition [0x00007fd4f1a59000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000acd84de8> (a java.util.concurrent.SynchronousQueue$TransferStack)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198)
at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:424)
at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323)
at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:874)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:945)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
说明：
1）“TIMED_WAITING (parking)”中的 timed_waiting 指等待状态，但这里指定了时间，到达指定的时间后自动退出等待状态；parking指线程处于挂起中。
2）“waiting on condition”需要与堆栈中的“parking to wait for <0x00000000acd84de8> (a java.util.concurrent.SynchronousQueue$TransferStack)”结合来看。首先，本线程肯定是在等待某个条件的发生，来把自己唤醒。其次，SynchronousQueue 并不是一个队列，只是线程之间移交信息的机制，当我们把一个元素放入到 SynchronousQueue 中时必须有另一个线程正在等待接受移交的任务，因此这就是本线程在等待的条件。
3）别的就看不出来了。
‘柒’ java 虚拟机内存因程序需要已确定在2—4G范围内，请问怎样分配该内存较好。请各位大神给出几套方案！
适合的才是最好的，不要盲目的加参数。
1. 首先呢，建议是把-Xms和-Xmx设置成一致，且设置为2G/4G,记得加-server参数,也就是在启动的命令行保证如下参数
java-server-Xms2000m-Xmx2000m
2. 上面就完成了JVM的基本配置，建议此时镇春对该JVM进行压力测试，并追加JVM的gc参数，分析内存的使用情况。
java-server-Xms2000m-Xmx2000m-Xloggc:$CATALINA_HOME/logs/gc.log
3. 使用HPjmter或jprofile等对JVM的内存回收日志gc.log进行分析。看内存瓶颈在哪里，在对应分析调整。春键这个性能调优不是随扒旅巧便调的，盲目的调会有负作用。如果上述软件不知道的请GOOGLE之。
‘捌’ jvm性能调优都做了什么
JVM是最好的软件工程之一，它为Java提供了坚实的基础，许多流行语言如Kotlin、Scala、Clojure、Groovy都使用JVM作为运行基础。一个专业的Java工程师必须要了解并掌握JVM，接下来就给大家分享Java基础知识中JVM调优相关知识点。
杭州Java基础知识学习之JVM调优讲解
JVM常见的调优参数包括：
-Xmx：指定java程序的最大堆内存, 使用java -Xmx5000M -version判断当前系统能分配的最大堆内存；
-Xms：指定最小堆内存, 通常设置成跟最大堆内存一样，减少GC；
-Xmn：设置年轻代大小。整个堆大小=年轻代大小+年老代大小。所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8；
-Xss：指定线程的最大栈空间, 此参数决定了java函数调用的深度, 值越大调用深度越深, 若值太小则容易出栈溢出错误(StackOverflowError)；
-XX:PermSize：指定方法区(永久区)的初始值,默认是物理内存的1/64，在Java8永久区移除, 代之的是元数据区，由-XX:MetaspaceSize指定；
-XX:MaxPermSize：指定方法区的最大值, 默认是物理内存的1/4，在java8中由-XX:MaxMetaspaceSize指定元数据区的大小；
-XX:NewRatio=n：年老代与年轻代的比值，-XX:NewRatio=2, 表示年老代与年轻代的比值为2:1；
-XX:SurvivorRatio=n：Eden区与Survivor区的大小比值，-XX:SurvivorRatio=8表示Eden区与Survivor区的大小比值是8:1:1，因为Survivor区有两个(from, to)。
JVM实质上分为三大块，年轻代(YoungGen)，年老代(Old Memory)，及持久代(Perm，在Java8中被取消)。
年轻代大小选择
响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。
吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。
年老代大小选择
响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得：并发垃圾收集信息、持久代并发收集次数、传统GC信息、花在年轻代和年老代回收上的时间比例。
减少年轻代和年老代花费的时间，一般会提高应用的效率。
吞吐量优先的应用：一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存活对象。
较小堆引起的碎片问题
因为年老代的并发收集器使用标记、清除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。但是，当堆空间较小时，运行一段时间以后，就会出现“碎片”，如果并发收集器找不到足够的空间，那么并发收集器将会停止，然后使用传统的标记、清除方式进行回收。如果出现“碎片”，可能需要进行如下配置：
-XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。
-XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次Full GC后，对年老代进行压缩。
‘玖’ java内存溢出是什么情况
首先先说一下JVM内存结构问题，JVM为两块：PermanentSapce和HeapSpace，其中x0dx0aHeap = }。PermantSpace负责保存反射对象，一般不用配置。JVM的Heap区可以通过-X参数来设定。x0dx0a 当一个URL被访问时，内存申请过程如下：x0dx0aA. JVM会试图为相关Java对象在Eden中初始化一块内存区域x0dx0aB. 当Eden空间足够时，内存申请结束。否则到下一步x0dx0aC. JVM试图释放在Eden中所有不活跃的对象（这属于1或更高级的垃圾回收）, 释放后若Eden空间仍然不足以放入新对象，则试图将部分Eden中活跃对象放入Survivor区x0dx0aD. Survivor区被用来作为Eden及OLD的中间交换区域，当OLD区空间足够时，Survivor区的对象会被移到Old区，否洞和消则会被保留在Survivor区x0dx0aE. 当OLD区空间不够时，JVM会在OLD区进行完全的垃圾收集（0级）x0dx0aF. 完全垃圾收集后，若Survivor及OLD区仍然无法存放从Eden复制过来的部分对象，导致JVM无法在Eden区为新对象创建内存区域，则出现”out of memory错误”x0dx0ax0dx0aJVM调优建议:x0dx0ax0dx0ams/mx：定义YOUNG+OLD段的总尺寸，ms为JVM启动时YOUNG+OLD的内存大小；mx为最大可占用的YOUNG+OLD内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所纳知花的开销。x0dx0aNewSize/MaxNewSize：定义YOUNG段的尺寸，NewSize为JVM启动时YOUNG的内存大小；MaxNewSize为最大可占用的YOUNG内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。x0dx0aPermSize/MaxPermSize：定义Perm段的尺寸，PermSize为JVM启动时Perm的内存大小；MaxPermSize为最大可占用的Perm内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。x0dx0aSurvivorRatio：设置Survivor空间和Eden空间的比例x0dx0ax0dx0a内存溢出的可能性x0dx0ax0dx0a1. OLD段溢出x0dx0a这种内存溢出是最常见的情况之一，产生的原因可能是：x0dx0a1) 设置的内存参数过小(ms/mx, NewSize/MaxNewSize)x0dx0a2) 程序问题x0dx0a单个程序持续进行消耗内存的处理，如循环几千次的字符串处理，对字符串处理应建议使用StringBuffer。此时不会报内存溢出错，却会使系统持续垃圾收集，无法处理其它请求，相关问题程序可通过Thread Dump获取（见系统问题诊断一章）单个程序所申请内存过大，有的程序会申请几十乃至几百兆内存，此时JVM也会因无法申请到资源而出现内存溢出，对此首先要找到相关功能，然后交予程序员修改，要找到相关程序，必须在Apache日志中寻找。x0dx0a当Java对象使用完毕后，其所引用的对象却没有销毁，使得JVM认为他还是活跃的对象而不进行回收，这样累计占用了大量内存而无法释放。由于目前市面上还没有对系统影响小的内存分析工具，故此时只能和程序员一起定位。x0dx0ax0dx0a2. Perm段溢出x0dx0a通常由于Perm段装载了大量的Servlet类而导致溢出，目前的解决办法：x0dx0a1) 将PermSize扩大，一般256M能够满足要求x0dx0a2) 若别无选择，则只能将servlet的路径加到CLASSPATH中，但一般不建议这么处理x0dx0ax0dx0a3. C Heap溢出x0dx0a系统对C Heap没有限制，故C Heap发生问题时，Java进程所占内存会棚配持续增长，直到占用所有可用系统内存x0dx0ax0dx0a参数说明:x0dx0ax0dx0aJVM 堆内存（heap）设置选项 x0dx0a 参数格式 x0dx0a 说 明 x0dx0a x0dx0a设置新对象生产堆内存（Setting the Newgeneration heap size） x0dx0a -XX:NewSize x0dx0a 通过这个选项可以设置Java新对象生产堆内存。在通常情况下这个选项的数值为1 024的整数倍并且大于1MB。这个值的取值规则为，一般情况下这个值-XX:NewSize是最大堆内存（maximum heap size）的四分之一。增加这个选项值的大小是为了增大较大数量的短生命周期对象 x0dx0ax0dx0a增加Java新对象生产堆内存相当于增加了处理器的数目。并且可以并行地分配内存，但是请注意内存的垃圾回收却是不可以并行处理的 x0dx0a x0dx0a设置最大新对象生产堆内存（Setting the maximum New generation heap size） x0dx0a -XX:MaxNewSize x0dx0a 通过这个选项可以设置最大Java新对象生产堆内存。通常情况下这个选项的数值为1 024的整数倍并且大于1MB x0dx0ax0dx0a其功用与上面的设置新对象生产堆内存-XX：NewSize相同x0dx0ax0dx0a设置新对象生产堆内存的比例（Setting New heap size ratios） x0dx0a -XX:SurvivorRatio x0dx0a 新对象生产区域通常情况下被分为3个子区域：伊甸园，与两个残存对象空间，这两个空间的大小是相同的。通过用-XX:SurvivorRatio=X选项配置伊甸园与残存对象空间（Eden/survivor）的大小的比例。你可以试着将这个值设置为8，然后监控、观察垃圾回收的工作情况x0dx0ax0dx0a设置堆内存池的最大值（Setting maximum heap size） x0dx0a -Xmx x0dx0a 通过这个选项可以要求系统为堆内存池分配内存空间的最大值。通常情况下这个选项的数值为1 024的整数倍并且大于1 MB x0dx0ax0dx0a一般情况下这个值（-Xmx）与最小堆内存（minimum heap size _Xms）相同，以降低垃圾回收的频度 x0dx0a x0dx0a取消垃圾回收 x0dx0a -Xnoclassgc x0dx0a 这个选项用来取消系统对特定类的垃圾回收。它可以防止当这个类的所有引用丢失之后，这个类仍被引用时不会再一次被重新装载，因此这个选项将增大系统堆内存的空间 x0dx0a x0dx0a设置栈内存的大小 x0dx0a -Xss x0dx0a 这个选项用来控制本地线程栈的大小，当这个选项被设置的较大（>2MB）时将会在很大程度上降低系统的性能。因此在设置这个值时应该格外小心，调整后要注意观察系统的性能，不断调整以期达到最优 x0dx0a x0dx0a最后说一句，你的机器的连接数设置也至关重要，连接的关闭最好把时间设置的少些，那些连接非常耗费资源。也是引起内存泄露的主要原因。
‘拾’ Tomcat调优
对于Tomcat的处理耗时较长的问题主要有当时的并发量、session数、内存及内存的回收等几个方面造成的。出现问题之后就要进行分析了。
1.关于Tomcat的session数目
这个可以直接从Tomcat的web管理界面去查看即可
或者借助于第三方工具Lambda Probe来查看，它相对于Tomcat自带的管理稍微多了点功能，但也不多
2.监视Tomcat的内存使用情况
使用JDK自带的jconsole可以比较明了的看到内存的使用情况，线程的状态，当前加载的类的总量等
JDK自带的jvisualvm可以下载插件（如GC等），可以查看更丰富的信息。如果是分析本地的Tomcat的话，还可以进行内存抽样等，检查每个类的使用情况
3.打印类的加载情况及对象的回收情况
这个可以通过配置JVM的启动参数，打印这些信息（到屏幕（默认也会到catalina.log中）或者文件），具体参数如下：
-XX:+PrintGC：输出形式：[GC 118250K->113543K(130112K), 0.0094143 secs] [Full GC 121376K->10414K(130112K), 0.0650971 secs]
-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:+：打印每次垃圾回收前，程序未中断的执行时间。可与上面混合使用。输出形式：Application time: 0.5291524 seconds
-XX:+PrintGCApplicationStoppedTime：打印垃圾拆蠢回收期间程序暂停的时间。可与上面混合使用。输出形式：Total time for which application threads were stopped: 0.0468229 seconds
-XX:PrintHeapAtGC: 打印GC前后的详庆顷细堆栈信息
-Xloggc:filename:与上面几个配合使用，把相关日志信息记录到文件以便分析
-verbose:class 监视加载的类的情况
-verbose:gc 在虚拟机发生内存回收时在输出设备显示信息
-verbose:jni 输出native方法调用的相关情况，一般用于诊断jni调用错误信息
4.添加JMS远程监控
对于部署在局域网内其它机器上的Tomcat，可以打开JMX监控端口，局域网其它机器就可以通过这个端口查看一些常用的参数（但一些比较复杂的功能不支持），同样是在JVM启动参数中配置即可，配置如下：
-Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false
-Djava.rmi.server.hostname=192.168.71.38 设置JVM的JMS监誉御陆控监听的IP地址，主要是为了防止错误的监听成127.0.0.1这个内网地址
-Dcom.sun.management.jmxremote.port=1090 设置JVM的JMS监控的端口
-Dcom.sun.management.jmxremote.ssl=false 设置JVM的JMS监控不实用SSL
-Dcom.sun.management.jmxremote.authenticate=false 设置JVM的JMS监控不需要认证
5.专业点的分析工具有
IBM ISA，JProfiler等，具体监控及分析方式去网上搜索即可。
单个Tomcat的处理性能是有限的，当并发量较大的时候，就需要有部署多套来进行负载均衡了。
集群的关键点有以下几点：
1.引入负载端
软负载可以使用nginx或者apache来进行，主要是使用一个分发的功能
参考：
http://ajita.iteye.com/blog/1715312（nginx负载）
http://ajita.iteye.com/blog/1717121（apache负载）
2.共享session处理
目前的处理方式有如下几种：
1).使用Tomcat本身的Session复制功能
参考http://ajita.iteye.com/blog/1715312（Session复制的配置）
方案的有点是配置简单，缺点是当集群数量较多时，Session复制的时间会比较长，影响响应的效率
2).使用第三方来存放共享Session
目前用的较多的是使用memcached来管理共享Session，借助于memcached-sesson-manager来进行Tomcat的Session管理
参考http://ajita.iteye.com/blog/1716320（使用MSM管理Tomcat集群session）
3).使用黏性session的策略
对于会话要求不太强（不涉及到计费，失败了允许重新请求下等）的场合，同一个用户的session可以由nginx或者apache交给同一个Tomcat来处理，这就是所谓的session sticky策略，目前应用也比较多
参考：http://ajita.iteye.com/blog/1848665（tomcat session sticky）
nginx默认不包含session sticky模块，需要重新编译才行（windows下我也不知道怎么重新编译）
优点是处理效率高多了，缺点是强会话要求的场合不合适
3.小结
以上是实现集群的要点，其中1和2可以组合使用，具体场景具体分析吧~
Tomcat本身还是运行在JVM上的，通过对JVM参数的调整我们可以使Tomcat拥有更好的性能。针对JVM的优化目前主要在两个方面：
1.内存调优
内存方式的设置是在catalina.sh中，调整一下JAVA_OPTS变量即可，因为后面的启动参数会把JAVA_OPTS作为JVM的启动参数来处理。
具体设置如下：
JAVA_OPTS="$JAVA_OPTS -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4"
其各项参数如下：
-Xmx3550m：设置JVM最大可用内存为3550M。
-Xms3550m：设置JVM促使内存为3550m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。
-Xmn2g：设置年轻代大小为2G。整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。
-Xss128k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。
-XX:NewRatio=4:设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5
-XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6
-XX:MaxPermSize=16m:设置持久代大小为16m。
-XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。
2.垃圾回收策略调优
垃圾回收的设置也是在catalina.sh中，调整JAVA_OPTS变量。
具体设置如下：
JAVA_OPTS="$JAVA_OPTS -Xmx3550m -Xms3550m -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100"
具体的垃圾回收策略及相应策略的各项参数如下：
串行收集器（JDK1.5以前主要的回收方式）
-XX:+UseSerialGC:设置串行收集器
并行收集器（吞吐量优先）
示例：
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100
-XX:+UseParallelGC：选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下，年轻代使用并发收集，而年老代仍旧使用串行收集。
-XX:ParallelGCThreads=20：配置并行收集器的线程数，即：同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。
-XX:+UseParallelOldGC：配置年老代垃圾收集方式为并行收集。JDK6.0支持对年老代并行收集
-XX:MaxGCPauseMillis=100:设置每次年轻代垃圾回收的最长时间，如果无法满足此时间，JVM会自动调整年轻代大小，以满足此值。
-XX:+UseAdaptiveSizePolicy：设置此选项后，并行收集器会自动选择年轻代区大小和相应的Survivor区比例，以达到目标系统规定的最低相应时间或者收集频率等，此值建议使用并行收集器时，一直打开。
并发收集器（响应时间优先）
示例：java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC
-XX:+UseConcMarkSweepGC：设置年老代为并发收集。测试中配置这个以后，-XX:NewRatio=4的配置失效了，原因不明。所以，此时年轻代大小最好用-Xmn设置。
-XX:+UseParNewGC: 设置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上，JVM会根据系统配置自行设置，所以无需再设置此值。
-XX:CMSFullGCsBeforeCompaction：由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。
-XX:+UseCMSCompactAtFullCollection：打开对年老代的压缩。可能会影响性能，但是可以消除碎片
3.小结
在内存设置中需要做一下权衡
1)内存越大，一般情况下处理的效率也越高，但同时在做垃圾回收的时候所需要的时间也就越长，在这段时间内的处理效率是必然要受影响的。
2)在大多数的网络文章中都推荐 Xmx和Xms设置为一致，说是避免频繁的回收，这个在测试的时候没有看到明显的效果，内存的占用情况基本都是锯齿状的效果，所以这个还要根据实际情况来定。
Tomcat的Connector是Tomcat接收HTTP请求的关键模块，我们可以配置它来指定IO模式，以及处理通过这个Connector接受到的请求的处理线程数以及其它一些常用的HTTP策略。其主要配置参数如下：
1.指定使用NIO模型来接受HTTP请求
protocol="org.apache.coyote.http11.Http11NioProtocol" 指定使用NIO模型来接受HTTP请求。默认是BlockingIO，配置为protocol="HTTP/1.1"
acceptorThreadCount="2" 使用NIO模型时接收线程的数目
2.指定使用线程池来处理HTTP请求
首先要配置一个线程池来处理请求（与Connector是平级的，多个Connector可以使用同一个线程池来处理请求）
<executor maxThreads="1000" minSpareThreads="50" maxIdleTime="600000"/>
<connector executor="tomcatThreadPool" 指定使用的线程池
3.指定BlockingIO模式下的处理线程数目
maxThreads="150"//Tomcat使用线程来处理接收的每个请求。这个值表示Tomcat可创建的最大的线程数。默认值200。可以根据机器的时期性能和内存大小调整，一般可以在400-500。最大可以在800左右。
minSpareThreads="25"---Tomcat初始化时创建的线程数。默认值4。如果当前没有空闲线程，且没有超过maxThreads，一次性创建的空闲线程数量。Tomcat初始化时创建的线程数量也由此值设置。
maxSpareThreads="75"--一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。默认值50。一旦创建的线程超过此数值，Tomcat会关闭不再需要的线程。线程数可以大致上用 “同时在线人数*每秒用户操作次数*系统平均操作时间” 来计算。
acceptCount="100"----指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理。默认值10。如果当前可用线程数为0，则将请求放入处理队列中。这个值限定了请求队列的大小，超过这个数值的请求将不予处理。
connectionTimeout="20000" --网络连接超时，默认值20000，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。
4.其它常用设置
maxHttpHeaderSize="8192" http请求头信息的最大程度，超过此长度的部分不予处理。一般8K。
URIEncoding="UTF-8" 指定Tomcat容器的URL编码格式。
disableUploadTimeout="true" 上传时是否使用超时机制
enableLookups="false"--是否反查域名，默认值为true。为了提高处理能力，应设置为false
compression="on" 打开压缩功能
compressionMinSize="10240" 启用压缩的输出内容大小，默认为2KB
noCompressionUserAgents="gozilla, traviata" 对于以下的浏览器，不启用压缩
compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain" 哪些资源类型需要压缩
5.小结
关于Tomcat的Nio和ThreadPool，本身的引入就提高了处理的复杂性，所以对于效率的提高有多少，需要实际验证一下。
6.配置示例
<connector redirectPort="8443"
maxThreads="150"
minSpareThreads="25"
maxSpareThreads="75"
acceptCount="100"
connectionTimeout="20000"
protocol="HTTP/1.1"
maxHttpHeaderSize="8192"
URIEncoding="UTF-8"
disableUploadTimeout="true"
enableLookups="false"
compression="on"
compressionMinSize="10240"
noCompressionUserAgents="gozilla, traviata"
compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain">
...
最后给大家分享Spring系列的学习笔记和面试题，包含spring面试题、spring cloud面试题、spring boot面试题、spring教程笔记、spring boot教程笔记、最新阿里巴巴开发手册（63页PDF总结）、2022年Java面试手册。一共整理了1184页PDF文档。私信博主（777）领取，祝大家更上一层楼！！！