环境： Redhat Advanced Server 4, jdk 1.4.2_06, tomcat 5.0.28

症状：jvm大概每一两天就要崩溃一次

解决过程：

 

hs_err_pidxxx.log 文件当中，前几行是：

 

 

An unexpected exception has been detected in native code outside the VM.

Unexpected Signal : 11 occurred at PC=0xB4ACA6

Function=strcpy+0x26

Library=/lib/tls/libc.so.6

 

Current Java thread:

at java.io.UnixFileSystem.deleteOnExit(Native Method)

at java.io.File.deleteOnExit(File.java:881)

at org.apache.commons.fileupload.DefaultFileItem.getTempFile(DefaultFileItem.java:620)

at org.apache.commons.fileupload.DefaultFileItem.getOutputStream(DefaultFileItem.java:557)

at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:406)


 
于是搜 UnixFileSystem deleteOnExit，果然发现
http://forums.oracle.com/forums/thread.jspa?threadID=816508&tstart=384

 
虽然这个是讲jrocket的，但是一样的：

 
The leak is in deleteOnExit - in a way. When you call deleteOnExit, the file is added to a list of files to be deleted when the VM exits. This list is managed in native memory. Files are never removed from the list, just added. They are not even removed if they are deleted. Thus, if you keep calling deleteOnExit you will leak an amount of memory for each call.

 
也就是说，commons file upload 经常的频繁调用temp file，导致jvm外部的内存溢出并且崩溃。

 
官方网站上也有相应的bug：
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6291034

 

 

commons file upload 网站上也有这个bug

https://issues.apache.org/jira/browse/FILEUPLOAD-95

 

并且 commons file upload 在1.1当中fix了。

所以最简单的办法就是把1.0升级成1.1 来搞定。

正在试验中，不知道长时间后会不会有问题。