tomcat内存溢出总结
解决溢出问题的方法
解决溢出问题的方法
解决溢出问题的方法主要有以下几种：
1. 代码审查和优化：通过仔细审查代码，找出可能导致溢出的源头，如大量数据的处理、循环引用等。
优化这些代码段，减少内存使用。
2. 调整内存参数：调整JVM的启动参数，如-Xms和-Xmx参数，可以动态调整内存分配。
这可以帮助避免内存溢出。
3. 使用内存分析工具：使用内存分析工具（如MAT）来分析内存使用情况，找出并解决内存泄漏问题。
4. 避免大对象分配：尽量避免一次性分配大量内存，可以将大任务拆分成小任务，逐个处理。
5. 优化数据库查询：数据库查询可能导致大量数据加载到内存中，可以通过优化查询语句，减少数据加载量。
6. 升级硬件：在某些情况下，增加物理内存或升级其他硬件（如硬盘）可能有助于解决溢出问题。
7. 使用缓存技术：对于频繁使用的数据，可以使用缓存技术来减少对数据库的访问，从而减少内存使用。
8. 日志分析：仔细分析应用程序日志，查找可能导致溢出的异常或错误。
9. 垃圾回收优化：根据应用程序的特点，选择合适的垃圾回收策略，以减少内存碎片和垃圾回收开销。
10. 避免第三方软件BUG：确保使用的第三方软件没有已知的内存泄漏问题或BUG，并及时更新软件。
这些方法可以根据实际情况进行选择和应用，一般需要通过不断测试和调优来找到最适合的解决方案。
排查内存溢出的方法和步骤
排查内存溢出的方法和步骤内存溢出是软件开发中常见的问题，它会严重影响程序的性能和稳定性。
为了确保软件的优质运行，及时排查和解决内存溢出问题至关重要。
本文将详细介绍排查内存溢出的方法和步骤。
一、了解内存溢出在排查内存溢出之前，我们需要了解什么是内存溢出。
内存溢出是指程序在运行过程中，申请的内存超过了系统能够提供的最大内存限制，导致程序无法正常运行。
内存溢出主要有以下几种类型：1.堆内存溢出：指程序在堆内存中申请的空间超过了限制。
2.栈内存溢出：指程序在栈内存中申请的空间超过了限制。
3.全局内存溢出：指程序在全局内存中申请的空间超过了限制。
二、排查内存溢出的方法1.分析程序代码（1）检查内存申请和释放的逻辑是否正确。
（2）检查是否存在内存泄露的情况，如已释放的内存还被程序使用。
（3）检查程序中是否存在大量临时对象创建和销毁，导致内存频繁申请和释放。
2.使用内存分析工具（1）Visual Studio Memory Profiler：适用于Windows平台的内存分析工具，可以监测程序运行过程中的内存使用情况，定位内存溢出问题。
（2）Valgrind：适用于Linux平台的内存分析工具，可以检测内存泄露、内存越界等问题。
（3）Xcode Memory Graph：适用于iOS和macOS平台的内存分析工具，可以查看内存使用情况，分析内存泄露等问题。
3.动态监测内存使用在程序运行过程中，实时监测内存使用情况，观察内存是否持续上升。
可以通过以下方法进行动态监测：（1）编写内存监控代码，定期输出程序内存使用情况。
（2）使用操作系统提供的命令行工具，如Windows的任务管理器、Linux的top和ps命令等。
三、排查内存溢出的步骤1.确定内存溢出的类型和范围。
2.使用分析工具或动态监测方法，定位内存溢出的问题代码。
3.修复问题代码，如优化内存申请和释放逻辑、消除内存泄露等。
4.重新运行程序，验证内存溢出问题是否已解决。
性能测试常见问题分析
性能测试常见问题分析⼀、内存溢出1、堆内存溢出现象： （1）压测执⾏⼀段时间后，系统处理能⼒下降。
这时⽤JConsole、JVisualVM等⼯具连上服务器查看GC情况，每次GC回收都不彻底并且可⽤堆内存越来越少。
（2）压测持续下去，最终在⽇志中有报错信息：ng.OutOfMemoryError.Java heap space。
排查⼿段： （1）使⽤jmap -histo pid > test.txt命令将堆内存使⽤情况保存到test.txt⽂件中，打开⽂件查看排在前50的类中有没有熟悉的或者是公司标注的类名，如果有则⾼度怀疑内存泄漏是这个类导致的。
（2）如果没有，则使⽤命令：jmap -dump:live,format=b,file=test.dump pid⽣成test.dump⽂件，然后使⽤MAT进⾏分析。
（3）如果怀疑是内存泄漏，也可以使⽤JProfiler连上服务器在开始跑压测，运⾏⼀段时间后点击“Mark Current Values”，后续的运⾏就会显⽰增量，这时执⾏⼀下GC，观察哪个类没有彻底回收，基本就可以判断是这个类导致的内存泄漏。
解决⽅式：优化代码，对象使⽤完毕，需要置成null。
2、永久代 / ⽅法区溢出现象：压测执⾏⼀段时间后，⽇志中有报错信息：ng.OutOfMemoryError: PermGen space。
产⽣原因：由于类、⽅法描述、字段描述、常量池、访问修饰符等⼀些静态变量太多，将持久代占满导致持久代溢出。
解决⽅法：修改JVM参数，将XX:MaxPermSize参数调⼤。
尽量减少静态变量。
3、栈内存溢出现象：压测执⾏⼀段时间后，⽇志中有报错信息：ng.StackOverflowError。
产⽣原因：线程请求的栈深度⼤于虚拟机所允许的最⼤深度，递归没返回，戒者循环调⽤造成。
解决⽅法：修改JVM参数，将Xss参数改⼤，增加栈内存。
栈内存溢出⼀定是做批量操作引起的，减少批处理数据量。
oom 内存溢出的排查思路
oom 内存溢出的排查思路以OOM（Out of Memory）内存溢出的排查思路为标题，我们将从以下几个方面来探讨如何解决这个问题。
1. 理解OOM内存溢出的原因OOM内存溢出是指应用程序在申请内存时，无法获得足够的内存空间而导致的错误。
这可能是因为应用程序的内存使用超过了系统分配给它的内存限制，或者是由于内存泄漏等问题导致的。
理解OOM的原因对于解决问题至关重要。
2. 分析错误日志在遇到OOM内存溢出问题时，首先应该分析错误日志。
错误日志通常会提供有关错误发生的位置、异常堆栈信息以及导致问题的原因的线索。
通过仔细阅读错误日志，可以确定问题的具体来源，并为解决问题提供指导。
3. 检查代码中的内存泄漏内存泄漏是导致OOM内存溢出的常见原因之一。
在排查问题时，需要仔细检查应用程序的代码，查找可能存在的内存泄漏点。
内存泄漏通常是由于未正确释放对象或者对象的生命周期管理不当导致的。
通过分析代码，可以找到潜在的内存泄漏点，并进行修复。
4. 检查内存使用情况除了检查代码中的内存泄漏，还应该对应用程序的内存使用情况进行监控和分析。
可以通过使用内存分析工具来获取应用程序的内存快照，并查看内存中存在的对象、其大小以及引用关系等信息。
通过对内存使用情况的分析，可以找到内存占用较大的对象，进一步缩小问题的范围。
5. 调整内存配置参数在一些情况下，OOM内存溢出可能是由于应用程序的内存配置参数设置不合理导致的。
例如，堆内存大小设置过小，无法满足应用程序的需求。
在排查问题时，可以尝试调整内存配置参数，增加堆内存大小或者调整垃圾回收算法等。
通过适当调整内存配置参数，可以有效地缓解或解决OOM内存溢出问题。
6. 优化代码和算法除了修复内存泄漏和调整内存配置参数外，还可以通过优化代码和算法来降低应用程序的内存占用。
例如，可以减少对象的创建和销毁次数，尽量复用对象，避免使用过多的静态变量等。
通过优化代码和算法，可以减少内存占用，提高应用程序的性能和稳定性。
Tomcat内存溢出及线程紊乱问题研究
Tomcat内存溢出及线程紊乱问题研究摘要：在很多基于B/S结构的网站架构中，WEB容器内存溢出及线程紊乱问题比较隐蔽，很多时候在测试阶段并不能发现，只有在现实中大规模数据和高并发量的情况下问题才逐渐的暴露出来。
因此，在网站正式发布前代码进行走查和技术改进，并修改相关服务器软件的配置，可以在很大程度上减少此类事件的发生。
本文以Tomcat为例，对WEB容器在数据传输过程中内存溢出及线程紊乱的表现、原因及解决方案作了简要论述。
关键词：Tomcat；WEB容器；内存溢出；线程紊乱随着Internet技术的普及，各地方学校、研究所和商业单位都在积极进行基础教育资源网和资源库的建设。
然而，随着资源网使用人数的不断增加，其并发量也在急剧增长，对WEB服务器的承压性和稳定性提出了新的挑战。
然而大多数WEB容器均有内存限制，因此，在服务器没有内存还有很大空缺的情况下，WEB容器内存首先溢出，经常报“OutOfMemory”错误，并与其他因素一道引发了线程紊乱，导致应用系统的某些功能重复执行，并且引起了数据库服务器崩溃、系统越来越慢直到死机等问题。
随着互联网技术的发展，基于WEB容器大规模数据传输以及并发量的需求已经日渐突出，而数据传输效率、WEB应用服务器性能以及应用系统的稳定性等因素直接影响了数据传输的质量。
在以Tomcat为WEB容器的环境中，若以上问题处理不当，则很多时候表现为Tomcat内存溢出以及线程紊乱，造成服务器宕机，严重影响正常的网站运行。
1Tomcat内存溢出及线程紊乱的主要表现Tomcat内存溢出主要是通过系统速度、系统性能表现以及系统日志来反映的。
通过对日志文件和系统表现的分析与判断，即可断定是否为内存溢出；线程紊乱是指在Web容器中发生的线程异常的情况，其很多时候是在内存溢出之后出现的，通过对应用系统的操作日志及WEB容器的相关日志即可判断。
1.1Tomcat内存溢出主要表现1）系统的速度越来越慢，甚至出现死机的现象。
内存溢出的三种情况及系统配置解决方案
内存溢出的三种情况及系统配置解决方案内存溢出是指程序在运行过程中申请的内存超过了系统或者进程所能提供的上限。
导致内存溢出的原因可能是程序中存在内存泄漏、内存分配过多或者递归调用过深等。
下面将介绍三种常见的内存溢出情况及其系统配置解决方案。
1.程序内存泄漏导致内存溢出：内存泄漏指程序在运行过程中动态分配内存空间后，没有对其进行释放，导致一部分内存无法再次使用。
长时间运行的程序中，如果内存泄漏较为严重，系统可用内存会不断减少，直到最终耗尽所有内存资源。
解决方案：使用内存泄漏检测工具来检测和修复程序中的内存泄漏问题。
同时，可以考虑使用自动内存管理的编程语言，如Java和Python，在程序运行过程中自动回收未使用的内存。
2.内存分配过多导致内存溢出：解决方案：优化程序的内存使用，尽可能减小内存分配的数量和大小。
可以通过使用更高效的内存管理算法来减少内存碎片，或者使用内存池技术来提前分配一定量的内存供程序使用。
3.递归调用过深导致内存溢出：递归函数在每次调用时会将一定量的数据压入栈中，如果递归调用层数过深，栈的空间可能会超过系统的限制，从而导致内存溢出。
这种情况通常发生在没有设置递归终止条件或者递归层数过多的情况下。
解决方案：优化递归算法，设置合适的递归终止条件，避免递归调用过深。
如果无法避免使用递归算法，可以考虑使用尾递归或者迭代算法来替代递归调用，减少栈的压力。
在系统配置方面，可以采取以下措施来预防和解决内存溢出问题：1.增加系统内存容量：如果内存溢出是由于系统可用内存不足引起的，可以考虑增加系统的内存容量。
这可以通过增加物理内存条或者使用虚拟内存技术来实现。
虚拟内存技术会将部分磁盘空间用作缓存，并将一部分数据暂时存储在磁盘上，以释放内存空间。
2. 调整JVM参数：对于使用Java虚拟机（JVM）的应用程序，可以通过调整JVM的参数来控制内存的分配和管理。
例如，可以通过设置-Xmx参数来限制JVM使用的最大堆内存大小，或者通过设置-XX:MaxPermSize参数来限制JVM使用的最大持久代（PermGen）内存大小。
session不及时释放导致内存溢出的功能问题分析
session不及时释放导致内存溢出的功能问题分析背景：做⼀个⽹站的时候，觉察服务器上⼀段⼯夫尤其不安宁，每隔⼀段⼯夫就会报”OutOfMemoryError： PermGen space”讹谬，于是⽹站也就歇菜了.安排环境：windows2003，tomcat6.0，spring mvc2.5帮助分析⼯具：jprofile6,visualvm,mat分析过程：1.⾃我察看阶段。
由于是报perm区失常，我率先想到，系统默认perm区太⼩，想想该当要调剂perm区⼤⼩，敞开catalina.bat，设置了JAVA_OPTS，JAVA_OPTS="-server -Xms512m -Xmx2048m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=784m"这么设置后，模仿歇菜时候的情形举⾏压⼒测验，觉察蛮安宁的，未曾揭⽰什么问题，这时⼜精细察看代码，⼤约就未曾揭⽰频繁创⽴不可回收的草芥对象，于是就先这么吧。
过了⼀段⼯夫觉察⼜出问题了，还是perm溢出。
随后我计算下perm区曾经够⼤了，怎么还会报这个失常，此刻极其弥蒙中....2.⼯具帮助分析。
visualvm 利⽤visualvm看看perm区是否真的像传说中说的那样---"perm溢出了"，看来还是恳挚点⽤apache⾃带的⼯具做压⼒测验看看是不是这个地⽅引起的测验⼯具⽤apache⾃带的 ./ab -n 100000 -c 40 http://om/class/kw-童卫⾐.html40个并发的时候perm区在30m处跌停，⼤约坚持0增长。
看来和perm区没联系。
perm区看下heap区觉察问题了 40并发下到尔后⼤约坚持5分钟顺次full gc了，这么开⼼啊，本来heap区出问题了，多个利⽤放在⼀个tomcat⾥的时候，万⼀⼀个利⽤刚好这么了，刚开始的heap，导航仪好像也没什么问题，烦闷了~~~继续弥蒙~~~~只能期待，等着出问题吧...半个⼩时过去了，还是这么....陡然觉察惊喜了。
java异常解决方案
java异常解决方案一、Hibernate（1）org.hibernate.TransientObjectException: object references an unsaved transient instance....（2）org.springframework.orm.hibernate3.HibernateSystemException: Don't change the reference to a collection withcascade="all-delete-orphan": entity.Klass.students; nested exception is org.hibernate.HibernateException: Don't change the reference to a collection with cascade="all-delete-orphan": entity.Klass.students二、Tomcat（1）tomcat启动时报错：java.io.EOFException（2）tomcat内存溢出三、JAVA基本（1）ng.ClassCastException:（2）ng.UnsupportedClassVersionError: Bad version number in .class file四、JSP（1）javax.servlet.jsp.JspException:（2）org.apache.jasper.JasperException: Unable to compile class for JSP:（3）Servlet.service() for servlet jsp threw exceptionng.Error: Unresolved compilation problem:（4）ng.Error: Unresolved compilation problem:The method contextInitialized(ServletContextEvent) of type CreateDataSourceTableListener must override a superclass method（5）Servlet.service() for servlet jsp threw exception ng.Error: Unresolved compilation problem:The method setCharacterEncoding(String) is undefined for the type ServletResponse五、SSH整合（1）ng.ClassNotFoundException:org.springframework.web.context.ContextLoaderListener（2）Exception starting filter struts2 Class:com.opensymphony.xwork2.spring.SpringObjectFactory File: SpringObjectFactory.java Method: getClassInstance（3）（7）（8）org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'biz' defined in class path... （4）Exception starting filter struts2The action name cannot be the same as the action suffix [Action] - Class: org.apache.struts2.convention.SEOActionNameBuilder （5）avax.management.RuntimeErrorException: Error thrown in preDeregister methodCaused by: ng.NoClassDefFoundError:org/apache/struts2/util/ObjectFactoryDestroyable（6）Unable to load configuration. - bean -jar:file:/D:/Tomcat/tomcat/apache-tomcat-6.0.30/webapps/tes t/WEB-INF/lib/struts2-core-2.2.3.1.jar!/struts-default.xml: 29:72六、Struts（1）ng.NoSuchMethodException:action.StudentAction.getAllStudent()（2）Caused by: ng.ClassCastException:org.apache.xerces.parsers.XML11Configuration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration （3）No result defined for action and result七、Android（1）There is no android project named 'cm-android'一、Hibernate一（1）org.hibernate.TransientObjectException: object references an unsaved transient instance - save the transient instance before flushing: er某个对象的某个属性是一个实体，在这个实体没有保存之前就保存这个对象而造成了这个错误。
Tomcat并发优化、内存配置、垃圾回收、宕机预防
Tomcat并发优化、内存配置、垃圾回收、宕机预防Tomcat并发优化、内存配置、垃圾回收、宕机预防⽬录Tomcat并发优化、内存配置、垃圾回收、宕机预防⽬录序⾔⼀、Tomcat并发优化(1) tomcat并发参数(2) tomcat并发配置⼆、Tomcat内存配置(1) tomcat内存参数(2) tomcat内存配置三、Tomcat垃圾回收(1) JVM中对象的划分及管理(2) jvm垃圾搜集参数(3) tomcat垃圾搜集配置四、Tomcat宕机预防(1) TCP端⼝状态(2) Windows系统下的TCP参数(3) tomcat假死分析及预防五、结语序⾔这⼏天系统问题层出不穷，服务器并发性差、tomcat内存溢出、假死宕机、⽹络阻塞，搞得我好不难受，寝⾷难安。
但是经过⾼⼈指点、⽹络资料，再加上实践运⾏测试，系统逐渐稳定下来，性能也提升了不少，轻松之余，为⼤家分享我的经历，希望⼤家能够有所收获。
⼀、Tomcat并发优化tomcat并发量与其配置息息相关，⼀般的机器⼏百的并发量⾜矣，如果设置太⾼可能引发各种问题，内存、⽹络等问题也能在⾼并发下暴露出来，因此，配置参数的设置⾮常重要。
(1) tomcat并发参数maxThreads：最⼤的并发请求数，当cpu利⽤率⾼的时候，不宜增加线程的个数,当cpu利⽤率不⾼，⼤部分是io阻塞类的操作时，可以适当增加该值。
maxSpareThreads：Tomcat连接器的最⼤空闲 socket 线程数acceptCount：当处理任务的线程数达到最⼤时，接受排队的请求个数connectionTimeout：⽹络连接超时，单位毫秒enableLookups：若为false则不进⾏DNS查询，提⾼业务能⼒应设置为falsedisableUploadTimeout：若为true则禁⽤上传超时 以上是⼀些⽐较常⽤的参数，Tomcat中server.xml配置详解会有更加详细的介绍。
Tomcat6 一些调优设置内存和连接数
Tomcat6 一些调优设置内存和连接数公司的一个服务器使用Tomcat6默认配置，在后台一阵全点击服务器就报废了，查了一下就要是PERMSIZE默认值过小造成（16-64）TOMCAT_HOME/bin/catalina.sh添加一行：JAVA_OPTS=" -XX:PermSize=64M -XX:MaxPermSize=128m"问题解决（可能为调用JAR包过多原因）下面是网上看到一些设置JAVA_OPTS="-server -Xms800m -Xmx800m -XX:PermSize=64M-XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true "当在对其进行并发测试时，基本上30个USER上去就当机了，还要修改默认连接数设置：以下红色四行TOMCAT6中好相没有，手工加上就可以了，基本上可以解决连接数过大引起的死机。
具体数值可跟据实际情况设置<Connector port="80" protocol="HTTP/1.1"maxThreads="600"minSpareThreads="100"maxSpareThreads="500"acceptCount="700"connectionTimeout="20000"redirectPort="8443" />这样设置以后，基本上没有再当机过。
maxThreads="600" ///最大线程数minSpareThreads="100"///初始化时创建的线程数maxSpareThreads="500"///一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。
内存溢出的解决思路
内存溢出的解决思路内存溢出是指应⽤系统中存在⽆法回收的内存或使⽤的内存过多，最终使得程序运⾏要⽤到的内存⼤于虚拟机能提供的最⼤内存。
引起内存溢出的原因有很多种，常见的有以下⼏种： 1.内存中加载的数据量过于庞⼤，如⼀次从数据库取出过多数据； 2.集合类中有对对象的引⽤，使⽤完后未清空，使得JVM不能回收； 3.代码中存在死循环或循环产⽣过多重复的对象实体； 4.使⽤的第三⽅软件中的BUG； 5.启动参数内存值设定的过⼩；内存溢出的解决⽅案：第⼀步，修改JVM启动参数，直接增加内存。
(-Xms，-Xmx参数⼀定不要忘记加。
) 第⼆步，检查错误⽇志，查看“OutOfMemory”错误前是否有其它异常或错误。
第三步，对代码进⾏⾛查和分析，找出可能发⽣内存溢出的位置。
重点排查以下⼏点： 1.检查对数据库查询中，是否有⼀次获得全部数据的查询。
⼀般来说，如果⼀次取⼗万条记录到内存，就可能引起内存溢出。
这个问题⽐较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，⼀次查询就有可能引起内存溢出。
因此对于数据库查询尽量采⽤分页的⽅式查询。
2.检查代码中是否有死循环或递归调⽤。
3.检查是否有⼤循环重复产⽣新对象实体。
4.检查对数据库查询中，是否有⼀次获得全部数据的查询。
⼀般来说，如果⼀次取⼗万条记录到内存，就可能引起内存溢出。
这个问题⽐较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，⼀次查询就有可能引起内存溢出。
因此对于数据库查询尽量采⽤分页的⽅式查询。
5.检查List、MAP等集合对象是否有使⽤完后，未清除的问题。
List、MAP等集合对象会始终存有对对象的引⽤，使得这些对象不能被GC回收。
第四步，使⽤内存查看⼯具动态查看内存使⽤情况从内存溢出看Java 环境中的内存结构 作为有个java程序员，我想⼤家对下⾯出现的这⼏个场景并不陌⽣，倍感亲切，深恶痛绝，抓⼼挠肝，⼀定会回过头来问为什么为什么为什么会这样，嘿嘿，让我们看⼀下我们⽇常在开发过程中接触内存溢出的异常： Exception in thread "main" [Full ng.OutOfMemoryError: Java heap spaceat java.util.Arrays.copyOf(Unknown Source)at java.util.Arrays.copyOf(Unknown Source)at java.util.ArrayList.grow(Unknown Source)at java.util.ArrayList.ensureExplicitCapacity(Unknown Source)at java.util.ArrayList.ensureCapacityInternal(Unknown Source)at java.util.ArrayList.add(Unknown Source)at oom.HeapOOM.main(HeapOOM.java:21) Exception in thread "main" ng.StackOverflowErrorat java.nio.CharBuffer.arrayOffset(Unknown Source)at sun.nio.cs.UTF_8.updatePositions(Unknown Source)at sun.nio.cs.UTF_8$Encoder.encodeArrayLoop(Unknown Source)at sun.nio.cs.UTF_8$Encoder.encodeLoop(Unknown Source)at java.nio.charset.CharsetEncoder.encode(Unknown Source)at sun.nio.cs.StreamEncoder.implWrite(Unknown Source)at sun.nio.cs.StreamEncoder.write(Unknown Source)at java.io.OutputStreamWriter.write(Unknown Source)at java.io.BufferedWriter.flushBuffer(Unknown Source)at java.io.PrintStream.write(Unknown Source)at java.io.PrintStream.print(Unknown Source)at java.io.PrintStream.println(Unknown Source)ng.OutOfMemoryError: PermGen spaceException in thread "main" ng.OutOfMemoryErrorat sun.misc.Unsafe.allocateMemory(Native Method)at oom.DirectMemoryOOM.main(DirectMemoryOOM.java:23) 是不是有⼤家很熟悉的，遇见这样的问题解决起来可能不简单，但是如果现在让⼤家写个程序，故意让程序出现下⾯的异常，估计能很快写出来的也不是很多，这就要求开发⼈员对于java内存区域以及jvm规范有⽐较深的了解。
tomcat OutOfMemory错误解决方法
tomcat OutOfMemory错误解决方法部署应用服务到tomcat下，可能会抛出内存溢出异常，如下：Exception in thread "Timer-1" ng.OutOfMemoryError: PermGen space为了解决tomcat在大进行大并发请求时，出现内存溢出的问题，请修改tomcat的内存大小，其中分为以下两种方式：一、使用catalina.bat 等命令行方式运行的tomcat1、windows环境下，修改tomcat\bin\Catalina.bat 文件在166行左右rem Execute Java with the applicable properties ”以下每行%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS%-Djava.endorsed.dirs="%JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%"-Dcatalina.base="%CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%"-Djava.io.tmpdir="%CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS% %ACTION%在%DEBUG_OPTS% 后面添加-Xms256m -Xmx512m2、linux环境下，打开在Tomcat的安装目录的bin文件的 ./bin/catalina.sh 文件,进入编辑状态.在注释后面加上如下脚本:JAVA_OPTS='-Xms512m -Xmx1024m'JAVA_OPTS="$JAVA_OPTS -server -XX:PermSize=64M -XX:MaxPermSize=256m"或者，在echo "Using CATALINA_BASE: $CATALINA_BASE" 下添加一行echo "Using CATALINA_BASE: $CATALINA_BASE"JAVA_OPTS="-server -XX:PermSize=64M -XX:MaxPermSize=128m"echo "Using CATALINA_HOME: $CATALINA_HOME"echo "Using CATALINA_TMPDIR: $CATALINA_TMPDIR"说明：JAVA_OPTS='-Xms512m -Xmx1024m' 是设置Tomcat使用的内存的大小； -XX:PermSize=64M-XX:MaxPermSize=256m 指定类空间(用于加载类)的内存大小保存后，重新以命令行的方式运行tomcat ，即可，然后通过最后面介绍的如何观察tomcat现有内存情况的方法进行查看是否已经变更成功。
使用MAT工具进行内存溢出定位及分析
内存溢出监控及分析问题所在一、内存溢出&内存泄漏的名词解释内存溢出（out of memory）：就是你要求分配的内存超出了系统能给你的，系统不能满足需求，于是产生溢出。
内存泄露（memory leak）：是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。
二、何时会抛出内存溢出错误何时会抛出OutOfMemoryException，并不是内存被耗空的时候才抛出∙JVM98%的时间都花费在内存回收∙每次回收的内存小于2%满足这两个条件将触发OutOfMemoryException，这将会留给系统一个微小的间隙以做一些Down之前的操作，比如手动打印Heap Dump。
Q：为什么崩溃前垃圾回收的时间越来越长？A：根据内存模型和垃圾回收算法，垃圾回收分两部分：内存标记、清除（复制），标记部分只要内存大小固定时间是不变的，变的是复制部分，因为每次垃圾回收都有一些回收不掉的内存，所以增加了复制量，导致时间延长。
所以，垃圾回收的时间也可以作为判断内存泄漏的依据Q：为什么Full GC的次数越来越多？A：因此内存的积累，逐渐耗尽了年老代的内存，导致新对象分配没有更多的空间，从而导致频繁的垃圾回收Q：为什么年老代占用的内存越来越大？A：因为年轻代的内存无法被回收，越来越多地被Copy到年老代三、内存溢出的一些现象现象1、后台日志会报错- Out of Memory当Java程序申请内存，超出VM可分配内存的时候，ＶＭ首先可能会垃圾回收(ＧＣ)，如果ＧＣ完还是不够，或者申请的直接超够ＶＭ可能有的，就会抛出内存溢出异常。
从ＶＭ规范中我们可以得到，以下几种异常：ng.StackOverflowError:（很少）ng.OutOfMemoryError：heap space(比较常见)ng.OutOfMemoryError: PermGen space (经常出现)ng.OutOfMemoryError: GC overhead limit exceeded（某项操作使用大量内存时发生）现象2、通过loadrunner的windows监控图的部分指标走势能猜测是否发生内存泄漏。
内存溢出的原因有哪些怎么解决
内存溢出的原因有哪些怎么解决内存溢出是指程序在申请内存空间时，由于申请的内存超过了系统能够提供给该程序的最大内存限制，导致系统无法为该程序分配足够的内存空间，从而引发错误或崩溃的情况。
内存溢出的原因是多方面的，下面将介绍其中一些常见的原因以及解决方法。
1. 资源泄露：资源泄露是指程序在使用资源后没有进行正确的释放，导致这些资源一直占据着内存空间。
常见的资源包括文件句柄、数据库连接、网络连接等。
解决方法是在使用完资源后及时关闭或释放这些资源，可以使用try-finally或try-with-resources语句块来确保资源的正确关闭。
2.内存泄露：内存泄露是指程序中的对象不再被使用，但由于一些原因（如被遗忘的引用、缓存未清理等），这些对象占据了内存空间而无法被垃圾回收机制回收。
解决方法是通过合理的设计和追踪内存使用情况，及时释放不再使用的对象的引用，避免对象的循环依赖等问题。
3.递归调用：当一个方法在自身内部不断地调用自己，而没有递归终止条件，就会导致无限递归，并占用大量的内存空间。
解决方法是在递归方法内部设置递归终止条件，避免无限递归的发生。
4.大对象：当程序需要创建非常大的对象，而内存空间不足以容纳这个大对象时，就会导致内存溢出。
解决方法是将大对象分割成多个小对象，或者使用流式处理来逐步处理大对象。
5.内存泄露：如使用者创建循环的静态集合，存储了对象，然后使用完对象不进行移除，导致内存泄漏，这些创建出来的对象不能被GC回收6.使用过多的本地变量：在方法、循环体或代码快内定义大量的本地变量，或者创建了大型的数组，可能会导致栈溢出异常。
解决方法是减少本地变量的数量或者使用动态数据结构来管理数据。
7.过度使用递归：递归调用是一种常见的内存溢出问题，递归调用的深度过大，可能导致栈空间不足，从而引发栈溢出异常。
解决方法是优化递归算法，尽量将递归转换为迭代方式，或者通过增加栈空间的大小来解决。
对于内存溢出问题的解决方法，可以从以下几个方面入手：1.减少或释放无用的资源：清理不再使用的资源，避免资源泄露和内存泄露问题的发生。
内存溢出的几种原因和解决办法
内存溢出的⼏种原因和解决办法对于JVM的内存写过的⽂章已经有点多了，⽽且有点烂了，不过说那么多⼤多数在解决OOM的情况，于此，本⽂就只阐述这个内容，携带⼀些分析和理解和部分扩展内容，也就是JVM宕机中的⼀些问题，OK，下⾯说下OOM的常见情况：第⼀类内存溢出，也是⼤家认为最多，第⼀反应认为是的内存溢出，就是堆栈溢出：那什么样的情况就是堆栈溢出呢？当你看到下⾯的关键字的时候它就是堆栈溢出了：ng.OutOfMemoryError: ......java heap space.....也就是当你看到heap相关的时候就肯定是堆栈溢出了，此时如果代码没有问题的情况下，适当调整-Xmx和-Xms是可以避免的，不过⼀定是代码没有问题的前提，为什么会溢出呢，要么代码有问题，要么访问量太多并且每个访问的时间太长或者数据太多，导致数据释放不掉，因为垃圾回收器是要找到那些是垃圾才能回收，这⾥它不会认为这些东西是垃圾，⾃然不会去回收了；主意这个溢出之前，可能系统会提前先报错关键字为：ng.OutOfMemoryError:GC over head limit exceeded这种情况是当系统处于⾼频的GC状态，⽽且回收的效果依然不佳的情况，就会开始报这个错误，这种情况⼀般是产⽣了很多不可以被释放的对象，有可能是引⽤使⽤不当导致，或申请⼤对象导致，但是java heap space的内存溢出有可能提前不会报这个错误，也就是可能内存就直接不够导致，⽽不是⾼频GC.第⼆类内存溢出，PermGen的溢出，或者PermGen 满了的提⽰，你会看到这样的关键字：关键信息为:ng.OutOfMemoryError: PermGen space原因：系统的代码⾮常多或引⽤的第三⽅包⾮常多、或代码中使⽤了⼤量的常量、或通过intern注⼊常量、或者通过动态代码加载等⽅法，导致常量池的膨胀，虽然JDK 1.5以后可以通过设置对永久带进⾏回收，但是我们希望的是这个地⽅是不做GC的，它够⽤就⾏，所以⼀般情况下今年少做类似的操作，所以在⾯对这种情况常⽤的⼿段是：增加-XX:PermSize和-XX:MaxPermSize的⼤⼩。
JVM内存溢出详解（栈溢出，堆溢出，持久代溢出、无法创建本地线程）
JVM内存溢出详解（栈溢出，堆溢出，持久代溢出、⽆法创建本地线程）1、内存溢出和内存泄漏的区别 内存溢出（Out Of Memory）：是指程序在申请内存时，没有⾜够的内存空间供其使⽤，出现Out Of Memory。
内存泄露（Memory Leak）：是指程序在申请内存后，由于某种原因⽆法释放已申请的内存空间，导致这块内存⽆法再次被利⽤，造成系统内存的浪费。
memory leak会最终会导致out of memory。
2、内存溢出分类2.1 栈内存溢出（StackOverflowError）： 程序所要求的栈深度过⼤导致，可以写⼀个死递归程序触发。
2.2 堆内存溢出(OutOfMemoryError : java heap space)需要分清是内存溢出还是内存泄漏：（1）如果是内存溢出，则通过调⼤ -Xms，-Xmx参数。
（2）如果是内存泄露，则看对象如何被 GC Root 引⽤。
2.3 持久带内存溢出(OutOfMemoryError: PermGen space)持久带中包含⽅法区，⽅法区包含常量池。
因此持久带溢出有可能是（1）运⾏时常量池溢出，也有可能是（2）⽅法区中保存的Class对象没有被及时回收掉或者Class信息占⽤的内存超过了我们配置。
⽤String.intern()触发常量池溢出。
Class对象未被释放，Class对象占⽤信息过多，有过多的Class对象。
可以导致持久带内存溢出。
2.4 ⽆法创建本地线程Caused by: ng.OutOfMemoryError:unable to create new native thread系统内存的总容量不变，堆内存、⾮堆内存设置过⼤，会导致能给线程分配的内存不⾜。
3、内存溢出详解3.1 栈溢出（StackOverflowError） 栈溢出抛出 StackOverflowError 错误，出现此种情况是因为⽅法运⾏的时候栈的深度超过了虚拟机容许的最⼤深度所致。
内存溢出出现原因及解决方案
内存溢出出现原因及解决方案篇一：内存溢出解决方案内存溢出解决方案篇二：内存溢出的三种情况及系统配置解决方案近经常有人咨询相关内存溢出的问题，在生产环境中tomcat内存设置不好很容易出现内存溢出。
造成内存原因是不一样的，当然处理方式也不一样。
这里根据平时遇到的情况和相关资料进行一个总结。
常见的一般会有下面三种情况：： Java heap space： PermGen space： unable to create new native thread.Tomcat内存溢出解决方案对于前两种情况，在应用本身没有内存泄露的情况下可以用设置tomcat jvm参数来解决。
（-Xms -Xmx -XX：PermSize -XX：MaxPermSize）最后一种可能需要调整操作系统和tomcat jvm参数同时调整才能达到目的。
第一种：是堆溢出。
在JVM中如果98％的时间是用于GC且可用的 Heap size不足2％的时候将抛出此异常信息。
没有内存泄露的情况下，调整-Xms -Xmx参数可以解决。
-Xms：初始堆大小-Xmx：最大堆大小但堆的大小受下面三方面影响：1.相关操作系统的数据模型（32-bt还是64-bit）限制；（32位系统下，一般限制在~2G；我在20XX server 系统下（物理内存：4G和6G，jdk：）测试 1612M，64为操作系统对内存无限制。
）2.系统的可用虚拟内存限制；3.系统的可用物理内存限制。
堆的大小可以使用 java -Xmx***M version 命令来测试。
支持的话会出现jdk的版本号，不支持会报错。
-Xms-Xmx一般配置成一样比较好比如set JAVA_OPTS= -Xms1024m -Xmx1024m第二种：永久保存区域溢出PermGen space的全称是Permanent Generation space，是指内存的永久保存区域。
这一部分用于存放Class和的信息，Class在被 Load的时候被放入PermGen space区域，它和和存放Instance的Heap区域不同，GC（Garbage Collection）不会在主程序运行期对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话，就很可能出现PermGen space错误。
oom 内存溢出的排查思路
oom 内存溢出的排查思路以oom（Out of Memory）内存溢出的排查思路为标题，我们将从以下几个方面进行讨论和分析。
一、理解内存溢出内存溢出指的是程序在申请内存时，没有足够的内存可供分配，导致程序无法正常运行或崩溃。
在Java中，内存溢出通常发生在堆内存（Heap）中，因为Java的对象都是在堆内存中分配的。
二、检查错误信息当程序发生oom内存溢出时，通常会抛出OutofMemoryError异常，并在错误信息中提供一些关键信息，如错误类型、错误位置等。
首先，我们需要仔细阅读错误信息，以了解问题的发生地点和可能的原因。
三、分析堆内存使用情况1.查看堆内存配置：检查Java虚拟机的堆内存配置参数（如-Xms 和-Xmx），确保分配的内存足够满足应用程序的需求。
2.监控堆内存使用情况：使用工具（如jstat、jvisualvm等）监控程序运行时的堆内存使用情况，包括堆内存大小、已使用内存、垃圾回收情况等。
通过对比峰值内存使用量和平均内存使用量，可以判断是否存在内存泄漏或内存消耗过大的问题。
四、检查代码中的内存泄漏1.查找可能引发内存泄漏的代码：仔细检查代码中是否存在未关闭的资源（如文件、数据库连接、网络连接等），以及未清理的缓存、集合等。
这些资源如果没有正确释放，会导致内存泄漏。
2.使用内存分析工具：借助工具（如Eclipse Memory Analyzer、VisualVM等），对程序进行内存分析。
通过工具提供的堆快照（Heap Dump）功能，可以查看对象的引用关系和内存占用情况，找出可能引发内存泄漏的对象。
五、优化代码和内存使用1.减少对象的创建：尽量避免频繁创建大量临时对象，可以使用对象池、缓存等方式进行优化。
2.及时释放资源：在代码中合理地释放资源，如关闭文件、数据库连接等。
3.优化数据结构和算法：合理选择数据结构和算法，避免使用过大的数据结构或低效的算法，从而减少内存消耗。
六、调整JVM参数1.增加堆内存：如果程序经过分析确实需要更多内存，可以适当增加堆内存配置参数（如-Xmx）。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
t o m c a t内存溢出总结-标准化文件发布号：（9556-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII
tomcat内存溢出总结
在生产环境中tomcat内存设置不好很容易出现内存溢出。
造成内存原因是不一样的，当然处理方式也不一样。
这里根据平时遇到的情况和相关资料进行一个总结。
常见的一般会有下面三种情况：
1.OutOfMemoryError: heap space
2.OutOfMemoryError: PermGen space
3.OutOfMemoryError: unable to create new native thread.
对于前两种情况，在应用本身没有内存泄露的情况下可以用设置tomcat jvm参数来解决。
（-Xms -Xmx -XX: PermSize -XX:MaxPermSize）
最后一种可能需要调整操作系统和tomcat jvm参数同时调整才能达到目的。
第一种：是堆溢出。
在JVM中如果98％的时间是用于GC且可用的 Heap size 不足2％的时候将抛出此异常信息。
没有内存泄露的情况下，调整-Xms -Xmx参数可以解决。
-Xms:初始堆大小
-Xmx:最大堆大小
但堆的大小受下面三方面影响：
1.相关操作系统的数据模型（32-bt还是64-bit）限制；（32位系统下，一般限制在1.5G~2G；我在2003 server 系统下（物理内存：4G和6G，jdk：1.6）1612M，64为操作系统对内存无限制。
）
2.系统的可用虚拟内存限制；
3.系统的可用物理内存限制。
堆的大小可以使用 java -Xmx***M version 命令来。
支持的话会出现jdk的版本号，不支持会报错。
-Xms -Xmx一般配置成一样比较好比如set JAVA_OPTS= -Xms1024m -
Xmx1024m
第二种：永久保存区域溢出
PermGen space的全称是Permanent Generationspace,是指内存的永久保存区域。
这一部分用于存放Class和Meta的信息,Class在被 Load的时候被放入PermGenspace区域，它和和存放Instance的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGenspace进行清理，所以如果你的APP 会LOAD很多CLASS的话,就很可能出现PermGenspace错误。
这种错误常见在web对JSP进行precompile的时候。
但目前的hibernate和spring项目中也很容易出现这样的问题。
/topic/80620?page=1 （具体连接内容见下）的帖子有讨论的这个问题。
可能是由于这些框架会动态class，而且jvm的gc是不会清理PemGen space的，导致内存溢出。
这一个一般是加大-XX: PermSize -XX:MaxPermSize 来解决问题。
-XX: PermSize 永久保存区域初始大小
-XX: PermSize 永久保存区域初始最大值
这一般结合第一条使用，比如 set JAVA_OPTS= -Xms1024m -Xmx1024m -XX: PermSize=128M -XX: PermSize=256M
有一点需要注意：java -Xmx***M version 命令来测试的最大堆内存是 -Xmx 与 -XX: PermSize的和比如系统支持最大的jvm堆大小事1.5G，那 -
Xmx1024m -XX: PermSize=768M 是无法运行的。
第三种：无法创建新的线程。
这种现象比较少见，也比较奇怪，主要是和jvm与系统内存的比例有关。
这种怪事是因为JVM已经被系统分配了大量的内存(比如1.5G)，并且它至少要占用可用内存的一半。
有人发现，在线程个数很多的情况下，你分配给JVM的内存越多，那么，上述错误发生的可能性就越大。
产生这种现象的原因如下（从这个blog中了解到原因：
/hexiong/blog ... b10c2542a75b3c.html）：每一个32位的进程最多可以使用2G的可用内存，因为另外2G被操作系统保留。
这里假设使用1.5G给JVM，那么还余下500M可用内存。
这500M内存中的一部分必须用于系统dll的加载，那么真正剩下的也许只有400M，现在关键的地方出现了：当你使用创建一个线程，在JVM的内存里也会创建一个Thread对象，但是同时也会在操作系统里创建一个真正的物理线程(参考JVM规范)，操作系统会在余下的400兆内存里创建这个物理线程，而不是在JVM的1500M的内存堆里创建。
在jdk1.4里头，默认的栈大小是256KB，但是在jdk1.5里头，默认的栈
大小为1M每线程，因此，在余下400M的可用内存里边我们最多也只能创建400个可用线程。
这样结论就出来了，要想创建更多的线程，你必须减少分配给JVM的最大内存。
还有一种做法是让JVM宿主在你的JNI代码里边。
给出一个有关能够创建线程的最大个数的估算公式：
(MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads
对于jdk1.5而言，假设操作系统保留120M内存：
1.5GB JVM: (2GB-1.5Gb-120MB)/(1MB) = ~380 threads
1.0GB JVM: (2GB-1.0Gb-120MB)/(1MB) = ~880 threads
在2000/XP/2003的boot.ini里头有一个启动选项，好像是：/PAE /3G ，可以让用户进程最大内存扩充至3G，这时操作系统只能占用最多1G的虚存。
那样应该可以让JVM创建更多的线程。
因此这种情况需要结合操作系统进行相关调整。
因此：我们需要结合不同情况对tomcat内存分配进行不同的诊断才能从根本上解决问题。
动态类导致永久保存区域溢出的jvm bug
SUN JDK+Tomcat 5.5.20运行服务的时候遇到问题，服务器跑几天后就会挂掉，并报ng.OutOfMemoryError: PermGen space异常。
发现很多人把问题归因于： spring,hibernate,tomcat，因为他们动态产生类,导致JVM中的permanent heap溢出。
然后解决方法众说纷纭，有人说升级tomcat版本到最新甚至干脆不用tomcat。
还有人怀疑spring的问题，在spring 论坛上讨论很激烈，因为spring在AOP时使用CBLIB会动态产生很多类。
但问题是为什么这些王牌的开源会出现同一个问题呢，那么是不是更基础的原因呢？tomcat在Q&A很隐晦的回答了这一点，我们知道这个问题，但这个问题是由一个更基础的问题产生。
于是有人对更基础的JVM做了检查，发现了问题的关键。
原来SUN 的JVM
把内存分了不同的区，其中一个就是permenter区用来存放用得非常多的类和类描述。
本来SUN设计的时候认为这个区域在JVM启动的时候就固定了，但他没有想到现在动态会用得这么广泛。
而且这个区域有特殊的垃圾收回机制，现在的问题是动态加载类到这个区域后，gc根本没办法回收！
2003年的时候就有一个bug报告给sun，但是到现在，这个bug还没有close！有人在这个bug加了句评语：“A bug this critical is open since 2003
Absolutely shameful.” 我觉得SUN在这个BUG上确实有些丢脸。
对这个bug最彻底的解决办法就是不要用SUN的JDK，而改用BEA的 JRokit. 打不过，还逃不过吗？有众多的选择，这就是开源的好。
：）。