相关文章推荐
WAS 内存溢出（OutofMemory）问题分析常用方法
简述 OOM（内存溢出）：
内存溢出是指在应用系统中存在无法回收的内存或内存使用的过多，最终导致应用程序无法为新的对象分配内存空间，这时J...
一、java.lang.OutOfMemoryError: native memory exhausted
Java 虚拟机初始堆大小和最大堆大小不能盲目设置
以前碰到不少做J2EE应用的同事。 他们...
写给自己看的,做个记录。
应用在Tomcat下跑的妥妥儿的， 在WebSphere 7.0.0.7中部署时，经常会出现部署超时，内存溢出等异常；就算部署上了，WebSphere自动重启等问题也比较困扰...
Java的GC机制是自动进行的，和c语言有些区别需要程序员自己保证内存的使用和回收。...
内存溢出与数据库锁表的问题，可以说是开发人员的噩梦，一般的程序异常，总是可以知道在什么时候或是在什么操作步骤上出现了异常，而且根据堆栈信息也很容易定位到程序中是某处出现了问题。内存溢出与锁表则不然，一...
D:\IBM\WebSphere\AppServer\profiles\AppSrv01\config\cells\Template-2008Node01Cell\nodes\Template-200...
跟WebSphere打交道几乎3年整，IBM软件部搞websphere的，800中心接电话的几乎都打过交道。
最开始我们的业务系统最大的问题就是内存溢出
一般来说溢出分2种，一种是heap堆溢出，...
build path各选项卡的意思也可以参考：
1、/link?url=1KDEFGydycob04vwmGhHocwXvGJFvoyfTGZSPtVU...
报错提示：
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (d...
他的最新文章
他的热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)论文发表、论文指导
周一至周五
9：00&22：00
基于JavaEE平台的WebSphere应用系统内存溢出浅析
　　[摘要]内存溢出(OOM)是很常见的WebSphere应用程序性能问题,它往往会导致系统响应速度变慢甚至服务器宕机。以一个基于JavaEE平台的ERP系统开发实践为背景,从应用程序和java虚拟机配置两个方面对OOM问题进行分析,并提出解决方案,从而改善系统性能。 中国论文网 /8/view-1067241.htm　　[关键词]JavaEEWebSphereOOM 　　中图分类号:TP3文献标识码:A文章编号:09) 　　 　　一、引言 　　 　　JavaEE(java Enterprise Edition)即Java平台企业版,是建立在Java SE平台基础上的企业级平台开发标准,它利用Java平台来简化企业解决方案的开发、部署和管理等相关复杂问题。 　　WebSphere是IBM研发的,所提供的一个集成软件平台,它包含编写、运行和监视随需应变的Web应用程序和跨平台解决方案所需要的整个中间件基础设施。WebSphere应用程序服务器(WAS)是整个基础设施的基础,所有其他产品都在它之上运行。 　　基于JavaEE的WebSphere应用日益广泛,但随着数据量不断增大、业务负载不断加重,性能问题可能就会暴露出来,相继出现客户响应速度慢、服务器内存不足、服务器CPU使用率100%等等瓶颈。 　　本文结合作者实际研发的一个ERP系统开发作为实践背景,主要分析内存溢出问题。 　　 　　二、内存溢出 　　 　　内存溢出(Out Of Memory,或简称OOM)是指应用系统中无法回收内存或使用的内存过多,导致程序运行所需内存大于虚拟机提供的最大内存。在Java中,内存管理是有JVM负责的,JVM一般采取堆(heap)的方式管理内存。Java堆是一个运行时数据区,类的实例从堆中分配空间。Java程序可以通过各种语句建立内存对象,但内存的释放是由垃圾回收器(Garbage Collection或简称GC)完成的。GC是全自动地检测并移除不在使用的数据对象。垃圾回收器通常由一定的条件按触发,在WebSphere用中主要是内存分配失败(Allocation Failure或简称AF)。由于不同的JVM实现者可能使用不同的算法来管理GC,同时不同类型的应用程序在不同的GC策略下也有所差异,因此笔者将针对Linux平台上,基于JDK1.5的IBM JVM来讨论内存溢出问题。 　　WAS服务器宕机后一般会自动产生javacore文件和Thread dump文件,或者手工生成,在Linux操作系统下可以采用命令kill -3 Java进程号生成。借助IBM工具IBM Thread and Monitor Dump Analyzer for Java分析javacore文件,图一是当java堆耗尽时显示的结果: 　　分析结果里面以灰色字体显示出java堆耗尽信息,在Garbage Collec 　　tion History里面也会提示对象分配失败信息: 　　J9AllocateObject() returning NULL!则表示Java堆分配对象未成功完成,将抛出OutOfMemoryError异常。 　　内存溢出可能由以下原因造成: 　　(1)一次性加载到内存的数据量过于庞大,使得Java堆空间耗尽; 　　(2)配置参数指定的JVM堆最大值太小; 　　(3)内存泄漏(Memory Leak)问题。 　　 　　三、内存溢出的解决 　　 　　内存溢出问题排查是比较棘手的,但还是有章可循的,以下结合笔者研发的ERP系统,介绍如何对内存溢出问题进行分析与解决。 　　 　　(一)JVM参数设置 　　WebSphere应用服务器是一个基于Java的进程,必须在一定的Java虚拟机环境下才能运行。在大多数的情况下,JVM堆大小影响着垃圾回收的执行频率和每次执行的时间。增大堆大小意味着会支持更多对象创建,由于大堆要用较长时间进行填充,在垃圾回收发生前应用程序会运行较长时间,所以系统吞吐率会增大。但是,较大堆也会用较长时间进行压缩,从而导致垃圾回收时间也较长。在WebSphere服务器JVM参数调优中,最重要的就是初始堆大小(-Xms)和最大堆大小(-Xmx)。通过这两个参数来限制内存堆的大小以满足Java应用程序的需求,合理的设置-Xms和-Xmx参数,对系统性能的提高具有重要的作用。最大堆也不能设置过大,尽管它最初通过延迟垃圾回收改进性能,但当垃圾回收时会运行较长时间。如何才能设置合理的-Xms与-Xmx参数,需要不断的观察与分析。通过IBM工具PMAT(PMAT工具解析JAVA SDK的详细垃圾回收日志,并提供统计信息,图标,分析并推荐java堆配置)对native_stderr.log日志进行分析。前提条件是WebSphere服务器开启详细垃圾回收(垃圾回收信息将默认记录在native_stderr.log日志文件中)。下面以笔者参与的ERP系统为例,来分析如何设置JVM的-Xmx与-Xms值。图三是显示的某时间段内垃圾回收的部分信息: 　　Used Tenured(After):指垃圾回收器进行垃圾回收之后,在堆的tenured区域中已经被使用的字节数。Free Tenured(After):指垃圾回收器进行垃圾回收之后,在堆的tenured区域中可用的字节数。Total Tenured(After):指垃圾回收器进行垃圾回收之后,堆的tenured区域的总字节数。 　　图四是对应的java堆Tenured区域的相关变化曲线,其中灰色曲线表示的是Total Tenured(After),黑色曲线表示的是Used Tenured(After)。 　　通过PMAT对native_stderr.log的分析,将java最大堆(-Xmx)设置成1024M,最小堆(-Xms)设置成512M,可以满足java应用程序的要求。目前,该系统在生产线上性能较好。 　　 　　(二)内存泄漏 　　内存泄漏原因有很多,一般来说,从数据库连接池、线程池中获取连接与释放连接比较容易造成内存泄漏。笔者参与的ERP系统采用的是c3p0连接池,hibernate3.0作为持久层。在利用hibernate开发DAO模块时,为了避免session的频繁创建和销毁以及提高系统性能,采用ThreadLocal模式来管理session比较合理。下面是获取session的核心代码: 　　public static final ThreadLocal 　　session =new ThreadLocal(); 　　public static Session currentSession() 　　throws HibernateException{ 　　Session s=session.get(); 　　if(s==null){ 　　s=sessionFactory.openSession();//打开连接 　　session.set(s);}} 　　session的关闭问题是最头疼的事情,如果在DAO层就把session关闭,因为hibernate存在lazy loading,那么在应用层内把关系结合都初始化(违背hibernate设计初衷,对性能有较大影响),否则hibernate就会抛session already closed E如果session不关闭,那么就必定会造成内存泄漏。笔者结合系统的运行环境以及系统访问量,采用的是open session in view模式来解决这种矛盾。将session绑定到当前线程,当某个新线程开启时,就自动在数据库连接池中获取连接,在线程结束后就自动释放连接。下面是核心代码: 　　public void doFilter(ServletRequestarg0, 　　ServletResponse arg1,FilterChain arg2) 　　throws IOException,ServletException{ 　　//自动获取连接 　　HiberanteSessionFacory.currentSession(); 　　try{ 　　arg2.doFilter(arg0,arg1); 　　}finally{//自动释放连接 　　HibernateSessionFactory.closeSession(); 　　}} 　　 　　(三)数据分页显示 　　对数据库查询中,尽量避免一次获得全部数据的查询。一般来说,如果一次取十万条记录到内存,就可能引起内存溢出,同时一次获取全部数据,速度也较慢。这个问题比较隐蔽,在上线前,数据库中数据较少,不容易出问题,上线后,数据库中数据多了,一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。 　　 　　四、结束语 　　 　　高性能是一个应用能成为企业级应用的重要前提,往往性能问题通常都比较复杂,一旦出现就不易解决。在系统开发中,应尽量避免可能造成的性能瓶颈。本文介绍了性能问题中的一个方面,即内存溢出,从三个方面进行分析,提出了在开发过程中如何避免内存溢出。 　　 　　参考文献: 　　[1]孙磊、孙静、楼亭、涂子琰等编著,《构建高性能WebSphere企业级应用》,电子工业大学出版社. 　　[2](美)文纳斯著,《深入java虚拟机》,机械工业出版社. 　　[3](美)尼尔森等著,《J2EE应用与IBM WebSphere》,电子工业出版社.
本文为全文原貌 未安装PDF浏览器用户请先下载安装 原版全文
转载请注明来源。原文地址：
【xzbu】郑重声明：本网站资源、信息来源于网络，完全免费共享，仅供学习和研究使用，版权和著作权归原作者所有，如有不愿意被转载的情况，请通知我们删除已转载的信息。
xzbu发布此信息目的在于传播更多信息，与本网站立场无关。xzbu不保证该信息（包括但不限于文字、数据及图表）准确性、真实性、完整性等。1166人阅读
J2EE（40）
公司CMS的tomcat又挂掉了,之前挂了一次.出现以下错误,后来把tomcat的内存增大到1024&
严重:&Exception&initializing&page&context&&
java.lang.OutOfMemoryError:&Java&heap&space&&
&&在tomcat\bin\catalina.bat的set&CURRENT_DIR=%cd%&前面添加&&
&&&&&&set&JAVA_OPTS&=-Xms512m&-Xmx1024m&&
&&&&&&意思:设置最小虚拟内存512,最大1024.&&
&&今天tomcat又挂了,一查之下,发现内存只升不降,久而久之,系统就挂死了.另外你可以用java的一个管理工具查看内存使用情况.在jdk1.6.0\bin\jconsole.exe.&&
&&&总结下内存只升不降的几个原因:&&
&&&1.在java中虽然有垃圾回收器，但是对rs等通过jdbc访问数据库的所产生的垃圾，它并不回收！&&
&&&&2.是否是循环套接层数太多导致资源得不到释放，或者存在死循环，后者的可能性恨大。&&
&&&&3.Tomcat&不支持EJB组件的开发，做j2ee项目时，最好还是用weblogic服务，而且在做基本的sql语句时，最好用连接池，不要多用jdbc,odbc桥，因为在建立连接时最耗时间&&
&&&&&解决方法是让tomcat自己管理内存,在startup.bat的@echo&off下面添加以下代码:&&
set&JAVA_OPTS=%JAVA_OPTS%&
-Dcom.sun.management.jmxremote.port=1090&
-Dcom.sun.management.jmxremote.ssl=false&
-Dcom.sun.management.jmxremote.authenticate=false&
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager&
-Djava.util.logging.config.file=&%CATALINA_HOME%\conf\logging.properties&&&
&&&&&然后再启动startup.bat,tomcat就会自己管理内存了.&&
&&&&&另外事实上，这是一个优化。因为对于操作系统，请求内存的系统调用会占用大量的cpu时间，所以频繁的请求、释放内存将会导致性能的严重下降。所以对于&jvm,最好的方式就是尽量多占用内存作为heap,少释放甚至不释放空闲的heap给操作系统以减少消耗在内存请求、释放操作上的cpu时间。&&
&&&&&&&PermGen&space的全称是Permanent&Generation&space,是指内存的永久保存区域OutOfMemoryError:&PermGen&space从表面上看就是内存益出，解决方法也一定是加大内存。说说为什么会内存益出：这一部分用于存放Class和Meta的信息,Class在被&Load的时候被放入PermGen&space区域，它和和存放Instance的Heap区域不同,GC(Garbage&Collection)不会在主程序运行期对PermGen&space进行清理，所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen&space错误。这种错误常见在web服务器对JSP进行pre&compile的时候。&&
改正方法：-Xms256m&-Xmx256m&-XX:MaxNewSize=256m&-XX:MaxPermSize=256m&
-------------------------------------------------------------------------------------------------------------------------------------
先试试这个：
-XX:PermSize=128M&
-XX:MaxNewSize=256m&
-XX:MaxPermSize=256m&&&
下面是找了2篇文章
设置Tomcat启动的初始内存
其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可
三、实例，以下给出1G内存环境下java jvm 的参数设置参考：
JAVA_OPTS=&-server -Xms800m -Xmx800m& -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true &
JAVA_OPTS=&-server -Xms768m -Xmx768m -XX:PermSize=128m -XX:MaxPermSize=256m -XX:&
NewSize=192m -XX:MaxNewSize=384m&
CATALINA_OPTS=&-server -Xms768m -Xmx768m -XX:PermSize=128m -XX:MaxPermSize=256m&
-XX:NewSize=192m -XX:MaxNewSize=384m&
在/usr/local/apache-tomcat-5.5.23/bin 目录下的catalina.sh
添加：JAVA_OPTS='-Xms512m -Xmx1024m'
要加“m”说明是MB，否则就是KB了，在启动tomcat时会 报内存不足。
-Xms：初始值
-Xmx：最大值
-Xmn：最小值
在catalina.bat最前面加入
set JAVA_OPTS=-Xms128m -Xmx350m&
如果用startup.bat启动tomcat,OK设置生效.够成功的分配200M内存.
但是如果不是执行startup.bat启动tomcat而是利用windows的系统服务启动tomcat服务,上面的设置就不生效了,
就是说set JAVA_OPTS=-Xms128m -Xmx350m 没起作用.上面分配200M内存就OOM了..
windows服务执行的是bin\tomcat.exe.他读取注册表中的值,而不是catalina.bat的设置.
修改注册表HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat Service Manager\Tomcat5\Parameters\JavaOptions
原值为
-Dcatalina.home=&C:\ApacheGroup\Tomcat 5.0&
-Djava.endorsed.dirs=&C:\ApacheGroup\Tomcat 5.0\common\endorsed&
加入 -Xms300m -Xmx350m&&
重起tomcat服务,设置生效&
Tomcat 的JVM 内存溢出问题的解决
关键字: tomcat 的jvm 内存溢出问题的解决&
最近在熟悉一个开发了有几年的项目，需要把数据库从mysql移植到oracle，首先把jdbc的连接指向mysql，打包放到tomcat里面，可以跑起来，没有问题，可是当把jdbc连接指向oracle的时候，tomcat就连续抛java.lang.OutOfMemoryError的错误，上网google了一下，了解了一下tomcat的运行机制，也解决了问题，share出来，以备查。&
1、首先是：java.lang.OutOfMemoryError: Java heap space&
Heap size 设置&
JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heap size的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。&
提示：在JVM中如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。&
提示：Heap Size 最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。&
解决方法：&
手动设置Heap size&
修改TOMCAT_HOME/bin/catalina.bat，在“echo &Using CATALINA_BASE: $CATALINA_BASE&”上面加入以下行：&
set JAVA_OPTS=%JAVA_OPTS% -server -Xms800m -Xmx800m -XX:MaxNewSize=256m&&&
set JAVA_OPTS=%JAVA_OPTS% -server -Xms800m -Xmx800m -XX:MaxNewSize=256m&
或修改catalina.sh&
在“echo &Using CATALINA_BASE: $CATALINA_BASE&”上面加入以下行：&
JAVA_OPTS=&$JAVA_OPTS -server -Xms800m -Xmx800m -XX:MaxNewSize=256m&&
2、其次是：java.lang.OutOfMemoryError: PermGen space&
PermGen space的全称是Permanent Generation space,是指内存的永久保存区域，这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中，它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的应用中有很CLASS的话,就很可能出现PermGen space错误，这种错误常见在web服务器对JSP进行pre
compile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。&
解决方法：&
1. 手动设置MaxPermSize大小&
修改TOMCAT_HOME/bin/catalina.bat（Linux下为catalina.sh），在Java代码&
“echo &Using CATALINA_BASE: $CATALINA_BASE&”上面加入以下行：&&&&
set JAVA_OPTS=%JAVA_OPTS% -server -XX:PermSize=128M -XX:MaxPermSize=512m&&&
“echo &Using CATALINA_BASE: $CATALINA_BASE&”上面加入以下行：&
set JAVA_OPTS=%JAVA_OPTS% -server -XX:PermSize=128M -XX:MaxPermSize=512m&
catalina.sh下为：&
JAVA_OPTS=&$JAVA_OPTS -server -XX:PermSize=128M -XX:MaxPermSize=512m&&&
JAVA_OPTS=&$JAVA_OPTS -server -XX:PermSize=128M -XX:MaxPermSize=512m&&
另外看到了另外一个帖子，觉得挺好，摘抄如下：&
分析java.lang.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根本没办法回收！&
对于以上两个问题，我的处理是：&
在catalina.bat的第一行增加：&
set JAVA_OPTS=-Xms64m -Xmx256m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m&&&
set JAVA_OPTS=-Xms64m -Xmx256m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m&
在catalina.sh的第一行增加：&
JAVA_OPTS=
-XX:PermSize=128M&
-XX:MaxNewSize=256m&
-XX:MaxPermSize=256m
-------------------------------------------------------------------------------------------------
Tomcat内存溢出的原因
　　在生产环境中tomcat内存设置不好很容易出现内存溢出。造成内存原因是不一样的，当然处理方式也不一样。
　　这里根据平时遇到的情况和相关资料进行一个总结。常见的一般会有下面三种情况：
　　1.OutOfMemoryError： Java heap space
　　2.OutOfMemoryError： PermGen space
　　3.OutOfMemoryError： 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位系统下，一般限制在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 Generation space，是指内存的永久保存区域。这一部分用于存放Class和Meta的信息，Class在被 Load的时候被放入PermGen space区域，它和和存放Instance的Heap区域不同，GC（Garbage Collection）不会在主程序运行期对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话，就很可能出现PermGen space错误。这种错误常见在web服务器对JSP进行pre compile的时候。但目前的hibernate和spring项目中也很容易出现这样的问题。？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中了解到原因：）：
　　每一个32位的进程最多可以使用2G的可用内存，因为另外2G被操作系统保留。这里假设使用1.5G给JVM，那么还余下500M可用内存。这500M内存中的一部分必须用于系统dll的加载，那么真正剩下的也许只有400M，现在关键的地方出现了：当你使用Java创建一个线程，在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内存分配进行不同的诊断才能从根本上解决问题。
　　以上就是针对Tomcat内存溢出的几种解决方案
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：119819次
积分：2011
积分：2011
排名：千里之外
原创：37篇
转载：287篇
评论：16条
(16)(31)(18)(3)(7)(3)(6)(7)(3)(10)(24)(6)(11)(16)(17)(28)(22)(6)(2)(2)(8)(1)(1)(3)(2)(3)(5)(1)(5)(3)(2)(13)(6)(19)(13)(1)
(window.slotbydup = window.slotbydup || []).push({
id: '4740887',
container: s,
size: '250,250',
display: 'inlay-fix'君，已阅读到文档的结尾了呢~~
基于JavaEE平台的WebSphere应用系统内存溢出浅析基于JavaEE平台的WebSphere应用系统内存溢出浅析［信息科学］余　　涛　　约3421字　　[摘要]内存溢出(OOM)是很常见的WebSphere应用程序性能问题,它往往会导致系统响应速度变慢甚至服务器宕机。以一个基于Jav...
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
基于JavaEE平台的WebSphere应用系统内存溢出浅析
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口