By Chris


2008-09-17 22:13:48 8 Comments

Recently I ran into this error in my web application:

java.lang.OutOfMemoryError: PermGen space

It's a typical Hibernate/JPA + IceFaces/JSF application running on Tomcat 6 and JDK 1.6. Apparently this can occur after redeploying an application a few times.

What causes it and what can be done to avoid it? How do I fix the problem?

30 comments

@Santosh Jadi 2016-03-22 07:15:00

The java.lang.OutOfMemoryError: PermGen space message indicates that the Permanent Generation’s area in memory is exhausted.

Any Java applications is allowed to use a limited amount of memory. The exact amount of memory your particular application can use is specified during application startup.

Java memory is separated into different regions which can be seen in the following image:

enter image description here

Metaspace: A new memory space is born

The JDK 8 HotSpot JVM is now using native memory for the representation of class metadata and is called Metaspace; similar to the Oracle JRockit and IBM JVM's.

The good news is that it means no more java.lang.OutOfMemoryError: PermGen space problems and no need for you to tune and monitor this memory space anymore using Java_8_Download or higher.

@Tim Howland 2008-09-18 02:09:46

resolved this for me as well; however, I noticed that the servlet restart times were much worse, so while it was better in production, it was kind of a drag in development.

@Yannis Sermetziadis 2011-06-06 09:20:45

Also if you are using log4j in your webapp, check this paragraph in log4j documentation.

It seems that if you are using PropertyConfigurator.configureAndWatch("log4j.properties"), you cause memory leaks when you undeploy your webapp.

@Satyadev 2016-10-02 15:27:47

If any one is struggling with the same error in netbeans, then here is how I fixed it.

In Netbeans:

Go to services tab --> Right on server -->Choose properties --> go to platform tab -->Inside vm options type -Xms1024m

In my case, I have given -Xms4096m

Here is the screenshot:

enter image description here

@Alejandro Pablo Tkachuk 2016-04-25 17:13:23

Assigning Tomcat more memory is NOT the proper solution.

The correct solution is to do a cleanup after the context is destroyed and recreated (the hot deploy). The solution is to stop the memory leaks.

If your Tomcat/Webapp Server is telling you that failed to unregister drivers (JDBC), then unregister them. This will stop the memory leaks.

You can create a ServletContextListener and configure it in your web.xml. Here is a sample ServletContextListener:

import java.sql.Driver;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.Enumeration;

import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;

import org.apache.log4j.Logger;

import com.mysql.jdbc.AbandonedConnectionCleanupThread;

/**
 * 
 * @author alejandro.tkachuk / calculistik.com
 *
 */
public class AppContextListener implements ServletContextListener {

    private static final Logger logger = Logger.getLogger(AppContextListener.class);

    @Override
    public void contextInitialized(ServletContextEvent arg0) {
        logger.info("AppContextListener started");
    }

    @Override
    public void contextDestroyed(ServletContextEvent arg0) {
        logger.info("AppContextListener destroyed");

        // manually unregister the JDBC drivers
        Enumeration<Driver> drivers = DriverManager.getDrivers();
        while (drivers.hasMoreElements()) {
            Driver driver = drivers.nextElement();
            try {
                DriverManager.deregisterDriver(driver);
                logger.info(String.format("Unregistering jdbc driver: %s", driver));
            } catch (SQLException e) {
                logger.info(String.format("Error unregistering driver %s", driver), e);
            }

        }

        // manually shutdown clean up threads
        try {
            AbandonedConnectionCleanupThread.shutdown();
            logger.info("Shutting down AbandonedConnectionCleanupThread");
        } catch (InterruptedException e) {
            logger.warn("SEVERE problem shutting down AbandonedConnectionCleanupThread: ", e);
            e.printStackTrace();
        }        
    }
}

And here you configure it in your web.xml:

<listener>
    <listener-class>
        com.calculistik.mediweb.context.AppContextListener 
    </listener-class>
</listener>  

@sendon1982 2016-01-05 01:04:17

First step in such case is to check whether the GC is allowed to unload classes from PermGen. The standard JVM is rather conservative in this regard – classes are born to live forever. So once loaded, classes stay in memory even if no code is using them anymore. This can become a problem when the application creates lots of classes dynamically and the generated classes are not needed for longer periods. In such a case, allowing the JVM to unload class definitions can be helpful. This can be achieved by adding just one configuration parameter to your startup scripts:

-XX:+CMSClassUnloadingEnabled

By default this is set to false and so to enable this you need to explicitly set the following option in Java options. If you enable CMSClassUnloadingEnabled, GC will sweep PermGen too and remove classes which are no longer used. Keep in mind that this option will work only when UseConcMarkSweepGC is also enabled using the below option. So when running ParallelGC or, God forbid, Serial GC, make sure you have set your GC to CMS by specifying:

-XX:+UseConcMarkSweepGC

@NIKHIL CHAURASIA 2015-09-04 09:33:38

I was having similar issue. Mine is JDK 7 + Maven 3.0.2 + Struts 2.0 + Google GUICE dependency injection based project.

Whenever i tried running mvn clean package command, it was showing following error and "BUILD FAILURE" occured

org.apache.maven.surefire.util.SurefireReflectionException: java.lang.reflect.InvocationTargetException; nested exception is java.lang.reflect.InvocationTargetException: null java.lang.reflect.InvocationTargetException Caused by: java.lang.OutOfMemoryError: PermGen space

I tried all the above useful tips and tricks but unfortunately none worked for me. What worked for me is described step by step below :=>

  1. Go to your pom.xml
  2. Search for <artifactId>maven-surefire-plugin</artifactId>
  3. Add a new <configuration> element and then <argLine> sub element in which pass -Xmx512m -XX:MaxPermSize=256m as shown below =>

<configuration> <argLine>-Xmx512m -XX:MaxPermSize=256m</argLine> </configuration>

Hope it helps, happy programming :)

@ 2008-12-05 11:43:23

App server PermGen errors that happen after multiple deployments are most likely caused by references held by the container into your old apps' classloaders. For example, using a custom log level class will cause references to be held by the app server's classloader. You can detect these inter-classloader leaks by using modern (JDK6+) JVM analysis tools such as jmap and jhat to look at which classes continue to be held in your app, and redesigning or eliminating their use. Usual suspects are databases, loggers, and other base-framework-level libraries.

See Classloader leaks: the dreaded "java.lang.OutOfMemoryError: PermGen space" exception, and especially its followup post.

@RockyMM 2012-06-07 17:21:06

This is only true solution to the problem, ableit in some cases too hard to implement.

@gavenkoa 2012-12-22 17:49:04

Another very good source is people.apache.org/~markt/presentations/… (from Tomcat release manager!!).

@Joachim Sauer 2013-04-09 10:30:48

Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.

@Darshan 2014-09-15 05:51:56

Perm gen space error occurs due to use large space rather then jvm provided space to executed the code. The best solution for this problem in UNIX operating systems is to change some configuration on bash file. Following steps solve the problem.

Run command gedit .bashrc on terminal.

Create JAVA_OTPS variable with following value:

export JAVA_OPTS="-XX:PermSize=256m -XX:MaxPermSize=512m"

Save the bash file. Run command exec bash on terminal. Restart the server.

I hope this approach will work on your problem. If you use a Java version lower than 8 this issue occurs sometimes. But if you use Java 8 the problem never occurs.

@faisalbhagat 2014-09-03 14:46:44

1) Increasing the PermGen Memory Size

The first thing one can do is to make the size of the permanent generation heap space bigger. This cannot be done with the usual –Xms(set initial heap size) and –Xmx(set maximum heap size) JVM arguments, since as mentioned, the permanent generation heap space is entirely separate from the regular Java Heap space, and these arguments set the space for this regular Java heap space. However, there are similar arguments which can be used(at least with the Sun/OpenJDK jvms) to make the size of the permanent generation heap bigger:

 -XX:MaxPermSize=128m

Default is 64m.

2) Enable Sweeping

Another way to take care of that for good is to allow classes to be unloaded so your PermGen never runs out:

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

Stuff like that worked magic for me in the past. One thing though, there’s a significant performance trade off in using those, since permgen sweeps will make like an extra 2 requests for every request you make or something along those lines. You’ll need to balance your use with the tradeoffs.

You can find the details of this error.

http://faisalbhagat.blogspot.com/2014/09/java-outofmemoryerror-permgen.html

@leomeurer 2014-10-17 16:59:04

Great post of @faisalbhagat faisalbhagat.blogspot.com/2014/09/…

@hdost 2015-04-16 05:05:37

Option 2 is great, but just be warned that it should not be used in production environments. Typically best to keep it to development environments only. However PermGen is removed as of Java 8 openjdk.java.net/jeps/122

@Edwin Buck 2014-08-04 13:01:13

The simplest answer these days is to use Java 8.

It no longer reserves memory exclusively for PermGen space, allowing the PermGen memory to co-mingle with the regular memory pool.

Keep in mind that you will have to remove all non-standard -XXPermGen...=... JVM startup parameters if you don't want Java 8 to complain that they don't do anything.

@bluish 2014-08-07 12:54:57

Hello, this answer has already been given: stackoverflow.com/a/22897121/505893. Please delete your answer, for clarity. If needed you could improve the answer I mentioned. Thanks ;)

@Edwin Buck 2014-08-07 13:01:08

@bluish Thank you for pointing that out; however, that answer goes all sideways on talking about OutOfMemoryExceptions and leaking metadata. It also fails to mention the very important points of removing the PermGen option. In short, I'm not sure I would be improving the answer, but rather rewriting it. If it was just a quick touch-up, I would feel less hesitant, but it looks like it would be much more than a quick touch-up, and I'd hate to offend the original author. Still, this answer list is a dog's dinner of a mess, and perhaps killing my post would be best anyway.

@kiwilisk 2011-12-08 14:51:19

I tried several answers and the only thing what finally did the job was this configuration for the compiler plugin in the pom:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>2.3.2</version>
    <configuration>
        <fork>true</fork>
        <meminitial>128m</meminitial>
        <maxmem>512m</maxmem>
        <source>1.6</source>
        <target>1.6</target>
        <!-- prevent PermGen space out of memory exception -->
        <!-- <argLine>-Xmx512m -XX:MaxPermSize=512m</argLine> -->
    </configuration>
</plugin>

hope this one helps.

@Alex 2012-05-22 19:47:40

"argLine" is not recognized by maven-compiler-plugin 2.4. it only supports "compilerArgument", which gives error: <compilerArgument>-XX:MaxPermSize=256m</compilerArgument> [ERROR] Failure executing javac, but could not parse the error: javac: invalid flag: -XX:MaxPermSize=256m Usage: javac <options> <source files>

@qwerty 2014-02-11 10:25:07

If your compilation phase is running out of permgen set the <compilerArgument> on the maven-compiler-plugin. If the unit tests are running out of permgen set <argLine> in the maven-surefire-plugin

@Peter 2012-01-04 02:26:08

Common mistakes people make is thinking that heap space and permgen space are same, which is not at all true. You could have lot of space remaining in the heap but still can run out of memory in permgen.

Common causes of OutofMemory in PermGen is ClassLoader. Whenever a class is loaded into JVM, all its meta data, along with Classloader, is kept on PermGen area and they will be garbage collected when the Classloader which loaded them is ready for garbage collection. In Case Classloader has a memory leak than all classes loaded by it will remain in memory and cause permGen outofmemory once you repeat it a couple of times. The classical example is Java.lang.OutOfMemoryError:PermGen Space in Tomcat.

Now there are two ways to solve this:
1. Find the cause of Memory Leak or if there is any memory leak.
2. Increase size of PermGen Space by using JVM param -XX:MaxPermSize and -XX:PermSize.

You can also check 2 Solution of Java.lang.OutOfMemoryError in Java for more details.

@Deckard 2012-01-20 01:15:44

How to pass param -XX:MaxPermSize and -XX:PermSize?? I can't find catalina.bat. My tomcat version is 5.5.26.

@Amit 2014-09-04 11:13:18

How to find the memory leaks of class loader ? Do you recommend any tool ?

@Barett 2015-04-23 18:35:41

@amit for tool recommendations, see the community wiki answer on this question.

@Zeb 2016-10-19 09:19:08

@Deckard going into the Tomcat/bin directory and running tomcat6w.exe. Under the "Java" tab, add the arguments to the "Java Options" box. Click "OK"

@dev 2012-09-01 07:32:49

You can also solve this problem by doing a:

rm -rf <tomcat-dir>/work/* <tomcat-dir>/temp/*

Clearing out the work and temp directories makes Tomcat do a clean startup.

@Chris 2008-09-17 22:17:16

The solution was to add these flags to JVM command line when Tomcat is started:

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

You can do that by shutting down the tomcat service, then going into the Tomcat/bin directory and running tomcat6w.exe. Under the "Java" tab, add the arguments to the "Java Options" box. Click "OK" and then restart the service.

If you get an error the specified service does not exist as an installed service you should run:

tomcat6w //ES//servicename

where servicename is the name of the server as viewed in services.msc

Source: orx's comment on Eric's Agile Answers.

@Taylor Leese 2009-05-27 18:51:53

The article below suggests -XX:+UseConcMarkSweepGC and -XX:MaxPermSize=128m as well. my.opera.com/karmazilla/blog/2007/03/13/…

@Eldelshell 2010-09-03 09:16:38

-XX:+CMSPermGenSweepingEnabled This option brings down performance. It makes each request take three times more time than usual on our systems. Use with care.

@sami 2010-12-10 14:44:55

worked for me - thanks - I am doing this on Ubuntu 10.10 with Tomcat6 - I created a new file: /usr/share/tomcat6/bin/setenv.sh and added the following line to that: JAVA_OPTS="-Xms256m -Xmx512m -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled" - Restarted tomcat using: sudo /etc/init.d/tomcat6 start

@knb 2011-07-27 11:59:31

On tomcat 6.0.29 startup, from my catalina.out logfile: "Please use CMSClassUnloadingEnabled in place of CMSPermGenSweepingEnabled in the future"

@stivlo 2011-07-30 18:40:37

On a tomcat 5.5 on Ubuntu I've changed /etc/default/tomcat5.5 with the following JAVA_OPTS="-Djava.awt.headless=true -Xms128M -Xmx512M -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=128m"

@false9striker 2012-03-14 06:03:45

I'm not able to open up tomcat6w.exe :( It says "The specified service does not exist as an installed service. Unable to open the service 'tomcat6' " . Could anyone help me on this?

@Nikem 2012-07-23 11:44:47

First of all it would be great to explain what these flags really do. Just saying: "do that and enjoy" is not enough IMHO.

@Nikem 2012-07-23 11:46:43

And second, if your application really leaks class loader, meaning that it leaves somewhere some object or class loaded by application's class loader even after undeployment, then these flags will not help. I have written blog post about this and other suggestions in this topic: plumbr.eu/blog/busting-permgen-myths

@Marko Vranjkovic 2013-05-15 15:32:47

-XX:+CMSClassUnloadingEnabled and -XX:+CMSPermGenSweepingEnabled are unusable in java 1.7, see link

@Abdull 2013-12-26 21:58:53

@lolotron, With Java OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)... running java -XX:+PrintFlagsFinal -version... the returned list of flags includes CMSClassUnloadingEnabled.

@Jack.W 2014-01-02 06:39:44

what if I use MAVEN, how can I do to solve the same problem?

@reallynice 2014-07-23 15:08:00

@lolotron vulgarly trying to set it on tomcat 7 on "Java HotSpot(TM) Server VM (build 24.45-b08, mixed mode)", it works fine (no more OutOfMemory errors).

@Senthil Kumar 2014-11-25 01:09:40

To know more about the flags - stackoverflow.com/questions/3334911/…

@J Slick 2015-10-27 17:54:40

A bit dated, like this thread, but here's documentation from Oracle: oracle.com/technetwork/java/…

@Ali Issa 2015-12-03 09:39:41

I can do this on tomcat 7: add this line to setenv.sh [JAVA_OPTS="-Xms256m -Xmx512m -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled" ] ? will this work?

@Kai Carver 2016-03-22 07:32:54

what worked for me on windows: created file ${tomcat-folder}\bin\setenv.bat containing one line: set JAVA_OPTS=-Dfile.encoding=UTF-8 -Xms128m -Xmx1024m -XX:PermSize=64m -XX:MaxPermSize=256m

@Alejandro Pablo Tkachuk 2016-04-25 17:18:52

The correct solution is to address the memory leak problems and resolve them. If you registered JDBC Drivers, unregister them. You can use a javax.servlet.ServletContextListener. I have posted a solution below with a sample code to unregister drivers / threads / etc.

@LucaP 2017-05-16 15:06:28

What if I'm running a WebLogic?

@rastaman 2017-08-08 13:33:57

Note that CMSClassUnloadingEnabled is enabled by default

@jonasespelita 2018-07-30 04:08:45

Any reason why these aren't enabled by default?

@Lucky 2013-03-20 10:08:37

  1. Open tomcat7w from Tomcat's bin directory or type Monitor Tomcat in start menu (a tabbed window opens with various service information).
  2. In the Java Options text area append this line:

    -XX:MaxPermSize=128m
    
  3. Set Initial Memory Pool to 1024 (optional).
  4. Set Maximum Memory Pool to 1024 (optional).
  5. Click Ok.
  6. Restart the Tomcat service.

@prayagupd 2013-03-03 10:05:44

I added -XX: MaxPermSize = 128m (you can experiment which works best) to VM Arguments as I'm using eclipse ide. In most of JVM, default PermSize is around 64MB which runs out of memory if there are too many classes or huge number of Strings in the project.

For eclipse, it is also described at answer.

STEP 1 : Double Click on the tomcat server at Servers Tab

enter image description here

STEP 2 : Open launch Conf and add -XX: MaxPermSize = 128m to the end of existing VM arguements.

enter image description here

@Chris Sim 2017-03-07 09:41:11

Thank you for your best detailed answer (Note : click "Open launch configuration" to open "edit configuration" window... but I used the following parameters: "-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled"

@Hugo Mendoza 2010-12-03 23:40:58

I had the problem we are talking about here, my scenario is eclipse-helios + tomcat + jsf and what you were doing is making a deploy a simple application to tomcat. I was showing the same problem here, solved it as follows.

In eclipse go to servers tab double click on the registered server in my case tomcat 7.0, it opens my file server General registration information. On the section "General Information" click on the link "Open launch configuration" , this opens the execution of server options in the Arguments tab in VM arguments added in the end these two entries

-XX: MaxPermSize = 512m
-XX: PermSize = 512m

and ready.

@Daniel 2010-11-29 19:36:41

The only way that worked for me was with the JRockit JVM. I have MyEclipse 8.6.

The JVM's heap stores all the objects generated by a running Java program. Java uses the new operator to create objects, and memory for new objects is allocated on the heap at run time. Garbage collection is the mechanism of automatically freeing up the memory contained by the objects that are no longer referenced by the program.

@sandeep 2010-04-28 04:51:04

Set -XX:PermSize=64m -XX:MaxPermSize=128m. Later on you may also try increasing MaxPermSize. Hope it'll work. The same works for me. Setting only MaxPermSize didn't worked for me.

@Nikem 2012-07-12 12:48:00

Increasing Permanent Generation size or tweaking GC parameters will NOT help if you have a real memory leak. If your application or some 3rd party library it uses, leaks class loaders the only real and permanent solution is to find this leak and fix it. There are number of tools that can help you, one of the recent is Plumbr, which has just released a new version with the required capabilities.

@bassist 2009-03-11 22:19:22

Try -XX:MaxPermSize=256m and if it persists, try -XX:MaxPermSize=512m

@igo 2013-04-12 08:30:30

and if it still persist try XX:MaxPermSize=1024m :)

@Thomas 2013-07-31 10:49:22

and if it still persist try XX:MaxPermSize=2048m :)

@Jonathan Airey 2014-10-06 11:25:57

And if it STILL persists, rethink your application!! Or try XX:MaxPermSize=4096m :)

@Jacek Pietal 2014-10-16 16:24:04

you can also try 8192m but thats a bit of overkill

@Joel Purra 2015-03-24 13:35:14

Overkill indeed -- 640KB ought to be enough for anybody!

@gzmask 2016-12-09 08:00:55

let's see... 2012 ppl say 1024, 2013 is 2048, 2014 it was 4096 and 2015 arrives at 8192. Now just spend that $100 for your 16384.

@Jeremy 2008-09-17 22:23:45

Alternatively, you can switch to JRockit which handling permgen differently then sun's jvm. It generally has better performance as well.

http://www.oracle.com/technetwork/middleware/jrockit/overview/index.html

@stracktracer 2012-07-27 07:25:03

While JRockit indeed has no PermGen, but this will not help in the long run. You'll get java.lang.OutOfMemoryError: There is insufficient native memory instead.

@Edward Torbett 2011-06-09 09:39:03

I've been butting my head against this problem while deploying and undeploying a complex web application too, and thought I'd add an explanation and my solution.

When I deploy an application on Apache Tomcat, a new ClassLoader is created for that app. The ClassLoader is then used to load all the application's classes, and on undeploy, everything's supposed to go away nicely. However, in reality it's not quite as simple.

One or more of the classes created during the web application's life holds a static reference which, somewhere along the line, references the ClassLoader. As the reference is originally static, no amount of garbage collecting will clean this reference up - the ClassLoader, and all the classes it's loaded, are here to stay.

And after a couple of redeploys, we encounter the OutOfMemoryError.

Now this has become a fairly serious problem. I could make sure that Tomcat is restarted after each redeploy, but that takes down the entire server, rather than just the application being redeployed, which is often not feasible.

So instead I've put together a solution in code, which works on Apache Tomcat 6.0. I've not tested on any other application servers, and must stress that this is very likely not to work without modification on any other application server.

I'd also like to say that personally I hate this code, and that nobody should be using this as a "quick fix" if the existing code can be changed to use proper shutdown and cleanup methods. The only time this should be used is if there's an external library your code is dependent on (In my case, it was a RADIUS client) that doesn't provide a means to clean up its own static references.

Anyway, on with the code. This should be called at the point where the application is undeploying - such as a servlet's destroy method or (the better approach) a ServletContextListener's contextDestroyed method.

//Get a list of all classes loaded by the current webapp classloader
WebappClassLoader classLoader = (WebappClassLoader) getClass().getClassLoader();
Field classLoaderClassesField = null;
Class clazz = WebappClassLoader.class;
while (classLoaderClassesField == null && clazz != null) {
    try {
        classLoaderClassesField = clazz.getDeclaredField("classes");
    } catch (Exception exception) {
        //do nothing
    }
    clazz = clazz.getSuperclass();
}
classLoaderClassesField.setAccessible(true);

List classes = new ArrayList((Vector)classLoaderClassesField.get(classLoader));

for (Object o : classes) {
    Class c = (Class)o;
    //Make sure you identify only the packages that are holding references to the classloader.
    //Allowing this code to clear all static references will result in all sorts
    //of horrible things (like java segfaulting).
    if (c.getName().startsWith("com.whatever")) {
        //Kill any static references within all these classes.
        for (Field f : c.getDeclaredFields()) {
            if (Modifier.isStatic(f.getModifiers())
                    && !Modifier.isFinal(f.getModifiers())
                    && !f.getType().isPrimitive()) {
                try {
                    f.setAccessible(true);
                    f.set(null, null);
                } catch (Exception exception) {
                    //Log the exception
                }
            }
        }
    }
}

classes.clear();

@Edward Torbett 2019-09-05 14:56:00

I know it's been over 8 years since I wrote this, but somewhere between then and now I found a deeper root cause and solution. This was that while all of the classes within the webapp are owned by the context classloader, the thread that invokes the startup and shutdown callback is owned by the parent classloader. This means that if the shutdown code initialises a thread-local variable, this will cause the parent classloader to end up holding a reference to the context classloader, preventing good cleanup.

@Edward Torbett 2019-09-05 15:01:00

Luckily, there's a very simple fix - move all code currently in the shutdown method into a new Thread object's run method. Then in the shutdown method, start this thread and wait for it to complete. The cleanup code will be executed identically, but any thread-local variables will remain bound to the context classloader instead of leaking.

@Maze 2011-03-19 11:38:19

I run into exactly the same problem, but unfortunately none of the suggested solutions really worked for me. The problem did not happen during deployment, and I was neither doing any hot deployments.

In my case the problem occurred every time at the same point during the execution of my web-application, while connecting (via hibernate) to the database.

This link (also mentioned earlier) did provide enough insides to resolve the problem. Moving the jdbc-(mysql)-driver out of the WEB-INF and into the jre/lib/ext/ folder seems to have solved the problem. This is not the ideal solution, since upgrading to a newer JRE would require you to reinstall the driver. Another candidate that could cause similar problems is log4j, so you might want to move that one as well

@Scot 2014-05-28 21:01:33

If you don't want to include the driver in jre/lib/ext, you could probably get the same results by including the driver in your container startup classpath. java -cp /path/to/jdbc-mysql-driver.jar:/path/to/container/bootstrap.‌​jar container.Start

@user17163 2008-09-18 03:29:11

Use the command line parameter -XX:MaxPermSize=128m for a Sun JVM (obviously substituting 128 for whatever size you need).

@Tim Howland 2008-09-18 03:35:47

The only issue is that you're just delaying the inevitable- at some point you'll run out of headroom there too. It's a great pragmatic solution, but it doesn't solve it permanently.

@Matt 2008-09-22 20:48:22

same thing occurs in Eclipse and any time you have lots of dynamic class loading. the classloaders aren't disposed of and live in the permanent generation for all eternity

@HDave 2011-10-31 15:15:50

I was running out of PermGen when executing a particularly large Hudson job...this fixed it for me.

@Péter Török 2011-12-14 08:50:47

@TimHowland, it can be a permanent fix if the root cause is not classloader leakage, just too many classes/static data in your web app.

@louisgab 2014-02-26 20:27:14

got the same issue as HDave when building jenkins/hudson from source.

@Pankaj Shinde 2009-07-01 04:54:18

I have a combination of Hibernate+Eclipse RCP, tried using -XX:MaxPermSize=512m and -XX:PermSize=512m and it seems to be working for me.

@toesterdahl 2009-05-07 15:15:28

You better try -XX:MaxPermSize=128M rather than -XX:MaxPermGen=128M.

I can not tell the precise use of this memory pool, but it have to do with the number of classes loaded into the JVM. (Thus enabling class unloading for tomcat can resolve the problem.) If your applications generates and compiles classes on the run it is more likely to need a memory pool bigger than the default.

@RockyMM 2012-06-07 17:23:28

Actually, this will only postpone OOMError. See answer below started by anon with two links to frankkieviet blog.

@amos 2014-02-13 18:27:18

These options are explained here: oracle.com/technetwork/java/javase/tech/…

@Hrishikesh Kumar 2010-11-18 12:48:24

In case you are getting this in the eclipse IDE, even after setting the parameters --launcher.XXMaxPermSize, -XX:MaxPermSize, etc, still if you are getting the same error, it most likely is that the eclipse is using a buggy version of JRE which would have been installed by some third party applications and set to default. These buggy versions do not pick up the PermSize parameters and so no matter whatever you set, you still keep getting these memory errors. So, in your eclipse.ini add the following parameters:

-vm <path to the right JRE directory>/<name of javaw executable>

Also make sure you set the default JRE in the preferences in the eclipse to the correct version of java.

@Ross Peoples 2010-09-20 17:40:48

"They" are wrong because I'm running 6.0.29 and have the same problem even after setting all of the options. As Tim Howland said above, these options only put off the inevitable. They allow me to redeploy 3 times before hitting the error instead of every time I redeploy.

Related Questions

Sponsored Content

19 Answered Questions

19 Answered Questions

[SOLVED] How to deal with "java.lang.OutOfMemoryError: Java heap space" error?

2 Answered Questions

[SOLVED] LDAP PermGen memory leak

5 Answered Questions

[SOLVED] java.lang.OutOfMemoryError: PermGen space error with Jetty

3 Answered Questions

[SOLVED] PermGen out of space before Max is reached

1 Answered Questions

[SOLVED] Explanation for this behaviour of Permgen space

5 Answered Questions

[SOLVED] java.lang.OutOfMemoryError: PermGen space on web app usage

Sponsored Content