This article analyzes the reasons why the Java program memory overflow is more detailed. Share it for everyone for your reference. The specifics are as follows:
Encountered a online system reported Java.lang.outoFMemoryerror: Permgen Space error, you need to locate the problem. I got this a long time ago, and I really don't remember it now, but this is really a very interesting question. It is worth studying. First of all, the first reaction is to add -xx:+Printgcdetails parameters to look at the specific GC logs, but because the program is started by Tomcat, I am worried that there are too many things encapsulated inside. alright.
Then let's take a look at the cause of this error. Find an explanation on the Internet.
The full name of Permgen Space is PerManent Generation Space, which refers to the permanent preservation area of memory. This memory is mainly stored by JVM and Meta information. When Class is loader, it will be placed in the PermGEN Space. (Instance) has different Heap regions. GC (GARBAGE Collection) will not clean up the Permgen Space during the main order of running, so if there is a very class in your application, the Permgen Space error is likely. This error is common in When the web server places Pre -Compile on JSP. If you use a large number of third -party jar under your web app, the size exceeds the default size (4M) of the JVM, then this error message will be generated.
Then let's increase the initial memory size of Permgen:
Add at the beginning of Linux at the beginning of the catalina.sh file: Copy code code as follows: java_opts = "-xms1024m -xmx1024m -XX: Permsize = 256m -xx: Maxpermsize = 256m" "" "
Plus at the beginning of the file of the Catalina.bat under Windows: Copy code code as follows: set java_opts = -xms1024m -xmx1024m -XX: Permsize = 256m -XX: MaxpermsSize = 256m
Then we still use visual memory to view tools to locate specific problems. The preferred tool for JDK6 is of course its own tools. The more commonly used JCONSOLE and JVISUALVM (the latter is found to be stronger after use because it has rich plug -in support). This time I encountered another weird problem, that is, the Tomcat process could not be found after the analysis tool was opened (JRE was found to be started afterwards, and it should be enough to change it to JDK).
Since the local area is not allowed, I can connect remotely, just open JMX.
Like the above, add the copy code code to the beginning of the java_opts of the catalina.sh.sh or catalina.bat file as follows: -djava.rmi.Server.hostname = 192.168.1.101-dcom.management.jmxremote.port = 900 0-- Dcom.sun.management.jmxremote.ssl = false -dcom.sun.management.jmxremote.authenticate = false
After starting the program, check whether the port is opened correctly to ensure that the remote can be connected.
I am lazy here and turn off Authenticate. It is more troublesome to set up something that needs to be set up. This settings are effective on my local PC, but it is not enough on the server. I may have seal the port to the port, so I had to make it cheap and change the port to 1000. Open jvisualvm, click File-> Add JMX Connection, and then add LocalHost: 1000 and connect.
After the previous program, observing the memory change for a period of time, I focused on the situation of Perm. It has been stabilized at 94m and running for a day is normal. It may be that the size of the PERM memory has not taken effect before, because Perm's default initialization is 16m and the maximum is 64M, and the actual occupation amount may indeed cause this problem. From the current phenomenon, this problem will not occur again. If you need to locate the problem further, you can also use BTRACE to view a place where a certain method is called. This can position whether certain methods are executed as expected.
It is hoped that this article is helpful to everyone's Java program design.