Out of Memory - Versionsgeschichte

Jochen: /* java.lang.OutOfMemoryError: Permgen space */

2016-09-30T10:11:09Z

java.lang.OutOfMemoryError: Permgen space

Jochen: /* What is a PermGen leak? */

2016-09-30T09:57:57Z

What is a PermGen leak?

← Nächstältere Version		Version vom 30. September 2016, 11:57 Uhr
Zeile 207:		Zeile 207:

	== What is a PermGen leak? ==		== What is a PermGen leak? ==

			''July 11, 2012 by Nikita Salnikov-Tarnovski''

	What follows is a practical introduction to a specific type of memory problems in Java applications. Namely – we will analyze the errors that cause the '''java.lang.OutOfMemoryError: PermGen''' spacesymptom in the stack trace.		What follows is a practical introduction to a specific type of memory problems in Java applications. Namely – we will analyze the errors that cause the '''java.lang.OutOfMemoryError: PermGen''' spacesymptom in the stack trace.

Jochen am 30. September 2016 um 09:57 Uhr

2016-09-30T09:57:32Z

← Nächstältere Version		Version vom 30. September 2016, 11:57 Uhr
Zeile 204:		Zeile 204:

	There are several ways to find out what has occupied the PermGen space in your JVM and whether the objects had a valid reason to fill it up. Memory dump analyzers, profilers, debuggers – the choice is yours. But if you need to be sure your PermGen is not filled up by garbage from a memory leak we can only recommend using [https://plumbr.eu/ Plumbr] and finding it out for free.		There are several ways to find out what has occupied the PermGen space in your JVM and whether the objects had a valid reason to fill it up. Memory dump analyzers, profilers, debuggers – the choice is yours. But if you need to be sure your PermGen is not filled up by garbage from a memory leak we can only recommend using [https://plumbr.eu/ Plumbr] and finding it out for free.


			== What is a PermGen leak? ==

			What follows is a practical introduction to a specific type of memory problems in Java applications. Namely – we will analyze the errors that cause the '''java.lang.OutOfMemoryError: PermGen''' spacesymptom in the stack trace.

			First of all we will go through the [https://plumbr.eu/blog/what-is-a-permgen-leak#intro core concepts] required to understand the subject – and explain what objects, classes, classloaders and the JVM memory model are. If you are familiar with the basic concepts, you can jump directly to the next section where I will describe two typical cases for the error in question alongside with hints and suggestions for solving it.


			=== Objects, Classes and ClassLoaders ===

			Well, I will not start with the very basics. I guess if you have found us, you should already be familiar with the concept that everything in Java is an '''Object'''. And that all Objects are specified by their '''Class'''. So every object has a reference to an instance of ''java.lang.Class'' describing the structure of that object’s class.

			But what actually happens under the hood when you create a new object in your code? For example if you write something truly complicated like


			<syntaxhighlight lang="java">
			Person boss = new Person()
			</syntaxhighlight>


			the Java Virtual Machine (JVM) needs to understand the structure of the object to create. To achieve this, the JVM looks for the class called Person. And if the Person class is accessed for the first time during this particular execution of the program, it has to be loaded by the JVM, normally from the corresponding Person.class file. The process of seeking for the Person.class file on the drive, loading it into memory and parsing it’s structure is called class loading. Ensuring proper class loading process is the responsibility of a '''ClassLoader'''. ClassLoaders are instances of ''java.lang.ClassLoader'' class and each and every class in a Java program has to be loaded by some ClassLoader. As a result we now have the following relationships:


			[[File:classloader1.png]]


			As you can see from the next diagram every classloader holds references to all the classes it has loaded. For the purpose of our article these relationships are very interesting.


			[[File:classloader2.png]]


			Remember this image, we will need it later.


			=== Permanent Generation ===

			Almost every JVM nowadays uses a separate region of memory, called the Permanent Generation (or '''PermGen''' for short), to hold internal representations of java classes. PermGen is also used to store more information – find out the details from this post if you are interested – but for our article it is safe to assume that only the class definitions are being stored in PermGen. The default size of this region on my two machines running java 1.6 is not a very impressive 82MB.


			[[File:sun-hotspot-memory-1.jpeg]]


			As I have explained in one of my earlier posts, a [https://plumbr.eu/blog/blog/what-is-a-memory-leak memory leak] in Java is a situation where some objects are no longer used by an application, but the '''Garbage Collector''' fails to recognize them as unused. This leads to the ''OutOfMemoryError'' if those unused objects contribute to the heap usage significantly enough that the next memory allocation request by the application cannot be fulfilled.

			The root cause of ''java.lang.OutOfMemoryError: PermGen space'' is exactly the same: the JVM needs to load the definition of a new class but there is not enough space in PermGen to do it – there are already too many classes stored there. A possible reason for this could be your application or server using too many classes for the current size of PermGen to be able to accommodate them. Another common reason could be a memory leak.


			=== Permanent Generation Leak ===

			But still, how on earth it is possible to leak something in PermGen? It holds definitions of java classes and they cannot become unused, can they? Actually, they can. In case of a Java web application deployed into an application server all those classes in your EAR/WAR become worthless when the application is undeployed. The JVM continues to run as the application server is still alive, but a whole bunch of class definitions are not in use anymore. And they should be removed from PermGen. If not, we will have memory leak in the PermGen area.

			As a nice sample on the reasons – the Tomcat developers have set up a [http://wiki.apache.org/tomcat/MemoryLeakProtection Wiki page] describing different leaks found and fixed in the Apache Tomcat versions 6.0.24 and above.


			=== Leaking Threads ===

			One possible scenario for a classloader leak is through long running threads. This happens when your application or – as often was the case in my experience – a 3rd party library used by your application starts some long running thread. An example of this could be a timer thread whose job is to execute some code periodically.

			If the intended lifespan of this thread is not fixed, we are heading directly into a trouble. When any part of your application ever starts a thread, you must make sure that it is not going to outlive the application. In typical cases the developer is either not aware of this responsibility or simply forgets to write the clean-up code.

			Otherwise, if some thread continues to run after the application is undeployed it will usually hold a reference to a classloader of the web application it was started by, called context classloader. Which in turn means that all classes of the undeployed application continue to be held in memory. Remedy? If it is your application that starts new threads, you should shut them down during undeployment using a servlet context listener. If it is a 3rd party library, you should search for its own specific shutdown hook. Or file a bug report if there is none.


			=== Leaking Drivers ===

			Another typical case of a leak can be caused by database drivers. We have encountered this leak in our own demo application that we ship with Plumbr. It is a slightly modified Pet Clinic application shipped along with Spring MVC. Let us highlight some things that happen when this application is being deployed to the server.

			* The server creates a new instance of java.lang.Classloader and starts to load the application’s classes using it.
			* Since the PetClinic uses a HSQL database, it loads the corresponding JDBC driver, ''org.hsqldb.jdbcDriver''.
			* This class, being a good-mannered JDBC driver, registers itself with ''java.sql.DriverManager'' during initialization, as required per JDBC specification. This registration includes storing inside a static field of DriverManager a reference to an instance of ''org.hsqldb.jdbcDriver''.

			Now, when the application is undeployed from the application server, the java.sql.DriverManager will still hold that reference, as there is no code in the HSQLDB library nor in the Spring framework nor in the application to remove that! As was explained above, a jdbcDriver object still holds a reference to an org.hsqldb.jdbcDriver class, which in turn holds a reference to the instance of java.lang.Classloader used to load the application. This classloader now still references all the classes of the application. In case of our particular demo application, during application startup almost 2000 classes are loaded, occupying roughly 10MB in PermGen. Which means that it takes about 5-10 redeploys to fill the PermGen with default size to reach the java.lang.OutOfMemoryError: PermGen space crash.

			How to fix that? One possibility is to write a servlet context listener, which de-registers the HSQLDB driver from DriverManager during application shutdown. This is pretty straightforward. But remember – you will have to write the corresponding code in every application using the driver.

			[http://www.plumbr.eu/ Download] our latest version of Plumbr with our demo application and play with it to find out how the leak occurs, how Plumbr finds it and how we explain the cause.


			=== Conclusion ===

			There are many reasons why your application might encounter a ''java.lang.OutOfMemoryError: PermGen space''. The root cause for the majority of them is some reference to an object or a class loaded by the application’s class loader that has died after that. Or a direct link to the class loader itself. The actions you need to take for remedy are quite similar for most of these causes. Firstly, find out where that reference is being held. Secondly, add a shutdown hook to your web application to remove the reference during application’s undeployment. You can do that by either using a servlet context listener or by using the API provided by your 3rd party library.

			Finding those leaking references has never been easy. We ourselves have spent countless hours trying to track down why some applications require 20MB of PermGen on each redeploy. But as of version 1.1,, Plumbr will show you the cause of the leak and give you a hint on how to fix it. If you want to try it out, [http://www.plumbr.eu/ register and download the tool].

Jochen: /* Solution for java.lang.OutOfMemoryError */

2016-09-29T20:44:18Z

Solution for java.lang.OutOfMemoryError

← Nächstältere Version		Version vom 29. September 2016, 22:44 Uhr
Zeile 134:		Zeile 134:
	As a result, a ''jdbcDriver'' object holds a reference to ''org.hsqldb.jdbcDriver'' class which in turn holds reference to the instance of ''java.lang.Classloader'' used to load the application. And that'''ClassLoader still references all classes of the application. In case of this particular demo application, almost 2000 classes are loaded during application startup. These occupy roughly 12MB''' in PermGen. Which means that it would take about seven redeploys to fill PermGen and get the “''java.lang.OutOfMemoryError: PermGen space''” error message in your logs.		As a result, a ''jdbcDriver'' object holds a reference to ''org.hsqldb.jdbcDriver'' class which in turn holds reference to the instance of ''java.lang.Classloader'' used to load the application. And that'''ClassLoader still references all classes of the application. In case of this particular demo application, almost 2000 classes are loaded during application startup. These occupy roughly 12MB''' in PermGen. Which means that it would take about seven redeploys to fill PermGen and get the “''java.lang.OutOfMemoryError: PermGen space''” error message in your logs.

	== Solution for java.lang.OutOfMemoryError ==		=== Solution for java.lang.OutOfMemoryError ===

	The first solution to the OutOfMemoryError due to PermGen should be obvious. If we have exhausted the PermGen area in the memory we need to increase its size. This solution is indeed helpful if you just have not given your JVM enough elbow room. So alter your application launch configuration and add (or increase if present) the following:		The first solution to the OutOfMemoryError due to PermGen should be obvious. If we have exhausted the PermGen area in the memory we need to increase its size. This solution is indeed helpful if you just have not given your JVM enough elbow room. So alter your application launch configuration and add (or increase if present) the following:

Jochen: /* Examples of java.lang.OutOfMemoryError */

2016-09-29T20:44:02Z

Examples of java.lang.OutOfMemoryError

← Nächstältere Version		Version vom 29. September 2016, 22:44 Uhr
Zeile 92:		Zeile 92:
	Most often such errors are triggered during the redeploy operations. When you are redeploying an application you are trying to get rid of the previous classloader referencing all the previously loaded classes and replace it with a classloader loading new versions of the classes. Unfortunately many libraries used within applications make it impossible to throw away the old classloader which means that during each redeploy all the previous versions of your classes will still reside in PermGen and consume the memory.		Most often such errors are triggered during the redeploy operations. When you are redeploying an application you are trying to get rid of the previous classloader referencing all the previously loaded classes and replace it with a classloader loading new versions of the classes. Unfortunately many libraries used within applications make it impossible to throw away the old classloader which means that during each redeploy all the previous versions of your classes will still reside in PermGen and consume the memory.

	== Examples of java.lang.OutOfMemoryError ==		=== Examples of java.lang.OutOfMemoryError ===

	'''Trivial example '''		'''Trivial example '''
Zeile 133:		Zeile 133:

	As a result, a ''jdbcDriver'' object holds a reference to ''org.hsqldb.jdbcDriver'' class which in turn holds reference to the instance of ''java.lang.Classloader'' used to load the application. And that'''ClassLoader still references all classes of the application. In case of this particular demo application, almost 2000 classes are loaded during application startup. These occupy roughly 12MB''' in PermGen. Which means that it would take about seven redeploys to fill PermGen and get the “''java.lang.OutOfMemoryError: PermGen space''” error message in your logs.		As a result, a ''jdbcDriver'' object holds a reference to ''org.hsqldb.jdbcDriver'' class which in turn holds reference to the instance of ''java.lang.Classloader'' used to load the application. And that'''ClassLoader still references all classes of the application. In case of this particular demo application, almost 2000 classes are loaded during application startup. These occupy roughly 12MB''' in PermGen. Which means that it would take about seven redeploys to fill PermGen and get the “''java.lang.OutOfMemoryError: PermGen space''” error message in your logs.


	== Solution for java.lang.OutOfMemoryError ==		== Solution for java.lang.OutOfMemoryError ==

Jochen: /* Cause of java.lang.OutOfMemoryError */

2016-09-29T20:43:39Z

Cause of java.lang.OutOfMemoryError

← Nächstältere Version		Version vom 29. September 2016, 22:43 Uhr
Zeile 75:		Zeile 75:


	== Cause of java.lang.OutOfMemoryError ==		=== Cause of java.lang.OutOfMemoryError ===

	To understand the cause for the “java.lang.OutOfMemoryError: PermGen space“, we need to start by reminding that everything in Java is represented as an Object. Also, all objects are instances from a specific Class. Even the Class declarations themselves are ultimately just very specific Objects. But what makes the class declarations interesting is the fact that on most JVMs Class declarations are loaded into a specific memory region, named Permanent Generation (PermGen for short).So – to recap: all Java classes are loaded and stored in the Java PermGen. This consists of the following:		To understand the cause for the “java.lang.OutOfMemoryError: PermGen space“, we need to start by reminding that everything in Java is represented as an Object. Also, all objects are instances from a specific Class. Even the Class declarations themselves are ultimately just very specific Objects. But what makes the class declarations interesting is the fact that on most JVMs Class declarations are loaded into a specific memory region, named Permanent Generation (PermGen for short).So – to recap: all Java classes are loaded and stored in the Java PermGen. This consists of the following:
Zeile 91:		Zeile 91:

	Most often such errors are triggered during the redeploy operations. When you are redeploying an application you are trying to get rid of the previous classloader referencing all the previously loaded classes and replace it with a classloader loading new versions of the classes. Unfortunately many libraries used within applications make it impossible to throw away the old classloader which means that during each redeploy all the previous versions of your classes will still reside in PermGen and consume the memory.		Most often such errors are triggered during the redeploy operations. When you are redeploying an application you are trying to get rid of the previous classloader referencing all the previously loaded classes and replace it with a classloader loading new versions of the classes. Unfortunately many libraries used within applications make it impossible to throw away the old classloader which means that during each redeploy all the previous versions of your classes will still reside in PermGen and consume the memory.


	== Examples of java.lang.OutOfMemoryError ==		== Examples of java.lang.OutOfMemoryError ==

Jochen am 29. September 2016 um 20:37 Uhr

2016-09-29T20:37:49Z

← Nächstältere Version		Version vom 29. September 2016, 22:37 Uhr
Zeile 91:		Zeile 91:

	Most often such errors are triggered during the redeploy operations. When you are redeploying an application you are trying to get rid of the previous classloader referencing all the previously loaded classes and replace it with a classloader loading new versions of the classes. Unfortunately many libraries used within applications make it impossible to throw away the old classloader which means that during each redeploy all the previous versions of your classes will still reside in PermGen and consume the memory.		Most often such errors are triggered during the redeploy operations. When you are redeploying an application you are trying to get rid of the previous classloader referencing all the previously loaded classes and replace it with a classloader loading new versions of the classes. Unfortunately many libraries used within applications make it impossible to throw away the old classloader which means that during each redeploy all the previous versions of your classes will still reside in PermGen and consume the memory.


	== Examples of java.lang.OutOfMemoryError ==		== Examples of java.lang.OutOfMemoryError ==
Zeile 139:		Zeile 140:
	The first solution to the OutOfMemoryError due to PermGen should be obvious. If we have exhausted the PermGen area in the memory we need to increase its size. This solution is indeed helpful if you just have not given your JVM enough elbow room. So alter your application launch configuration and add (or increase if present) the following:		The first solution to the OutOfMemoryError due to PermGen should be obvious. If we have exhausted the PermGen area in the memory we need to increase its size. This solution is indeed helpful if you just have not given your JVM enough elbow room. So alter your application launch configuration and add (or increase if present) the following:

			<syntaxhighlight lang="text">
	-XX:MaxPermSize=512m		-XX:MaxPermSize=512m
			</syntaxhighlight>


	This configuration parameter is indicating to the JVM that PermGen is allowed to grow up to 512 MB before complaining in the form of OutOfMemoryError.		This configuration parameter is indicating to the JVM that PermGen is allowed to grow up to 512 MB before complaining in the form of OutOfMemoryError.
Zeile 147:		Zeile 151:
	This can become a problem when the application is creating lots of classes dynamically and the generated classes are not needed for longer periods. In such a case, allowing JVM to unload class definitions can be helpful. This is achieved by adding again just one configuration parameter to your startup scripts:		This can become a problem when the application is creating lots of classes dynamically and the generated classes are not needed for longer periods. In such a case, allowing JVM to unload class definitions can be helpful. This is achieved by adding again just one configuration parameter to your startup scripts:

			<syntaxhighlight lang="text">
	-XX:+CMSClassUnloadingEnabled		-XX:+CMSClassUnloadingEnabled
			</syntaxhighlight>


	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 parallel or, God forbid, serial GCs, make sure you have set your GC to CMS by specifying:		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 parallel or, God forbid, serial GCs, make sure you have set your GC to CMS by specifying:

			<syntaxhighlight lang="text">
	-XX:+UseConcMarkSweepGC		-XX:+UseConcMarkSweepGC
			</syntaxhighlight>


	But before calling it a night, be warned – more often than not usage of the recommended ~~“quick fixes”~~ means you are just masking the symptoms by hiding ~~''“java~~.lang.OutOfMemoryError: Permgen ~~space” ''~~and are not tackling the underlying problem.		But before calling it a night, be warned – more often than not usage of the recommended "quick fixes" means you are just masking the symptoms by hiding "java.lang.OutOfMemoryError: Permgen space" and are not tackling the underlying problem.

	For example, if you really want to fix the leakage in PermGen we introduced in the examples section, the following servlet context listener can be used:		For example, if you really want to fix the leakage in PermGen we introduced in the examples section, the following servlet context listener can be used:

	public class JdbcDriverLeakPreventer implements ServletContextListener {~~<br />~~		<syntaxhighlight lang="text">
	@Override~~<br />~~		public class JdbcDriverLeakPreventer implements ServletContextListener {
	public void contextInitialized(ServletContextEvent sce) {~~<br />~~		@Override
	//Nothing to do~~<br />~~		public void contextInitialized(ServletContextEvent sce) {
	}~~<br />~~		//Nothing to do
	~~<br />~~		}
	@Override~~<br />~~
	public void contextDestroyed(ServletContextEvent sce) {~~<br />~~		@Override
	ClassLoader applicationClassLoader = this.getClass().getClassLoader();~~<br />~~		public void contextDestroyed(ServletContextEvent sce) {
	Enumeration driverEnumeration = DriverManager.getDrivers();~~<br />~~		ClassLoader applicationClassLoader = this.getClass().getClassLoader();
	while (driverEnumeration.hasMoreElements()) {~~<br />~~		Enumeration driverEnumeration = DriverManager.getDrivers();
	Driver driver = driverEnumeration.nextElement();~~<br />~~
	ClassLoader driverClassLoader = driver.getClass().getClassLoader();~~<br />~~		while (driverEnumeration.hasMoreElements()) {
	if (driverClassLoader != null~~<br />~~		Driver driver = driverEnumeration.nextElement();
	&~~amp;~~&~~amp;~~ driverClassLoader.equals(applicationClassLoader)){~~<br />~~		ClassLoader driverClassLoader = driver.getClass().getClassLoader();
	try {~~<br />~~
	DriverManager.deregisterDriver(driver);~~<br />~~		if (driverClassLoader != null && driverClassLoader.equals(applicationClassLoader)){
	} catch (SQLException e) {~~<br />~~		try {
	e.printStackTrace(); //TODO Replace with your exception handling~~<br />~~		DriverManager.deregisterDriver(driver);
	}~~<br />~~		} catch (SQLException e) {
	}~~<br />~~		e.printStackTrace(); //TODO Replace with your exception handling
	}~~<br />~~		}
	}~~<br />~~		}
			}
			}
	}		}
			</syntaxhighlight>


	This Servlet listener should be registered, for example, in the web.xml file of your application:		This Servlet listener should be registered, for example, in the web.xml file of your application:

	~~<~~listener~~><br /~~>		<syntaxhighlight lang="text">
	~~<~~listener-class~~>~~user.package.JdbcDriverLeakPreventer~~<~~/listener-class~~>~~<br />		<listener>
	~~<~~/~~listener>~~		<listener-class>user.package.JdbcDriverLeakPreventer</listener-class>
			</listener>
			</syntaxhighlight>


	There are several ways to find out what has occupied the PermGen space in your JVM and whether the objects had a valid reason to fill it up. Memory dump analyzers, profilers, debuggers – the choice is yours. But if you need to be sure your PermGen is not filled up by garbage from a memory leak we can only recommend using [https://plumbr.eu/ Plumbr] and finding it out for free.		There are several ways to find out what has occupied the PermGen space in your JVM and whether the objects had a valid reason to fill it up. Memory dump analyzers, profilers, debuggers – the choice is yours. But if you need to be sure your PermGen is not filled up by garbage from a memory leak we can only recommend using [https://plumbr.eu/ Plumbr] and finding it out for free.

Jochen am 29. September 2016 um 20:33 Uhr

2016-09-29T20:33:55Z

← Nächstältere Version		Version vom 29. September 2016, 22:33 Uhr
Zeile 92:		Zeile 92:
	Most often such errors are triggered during the redeploy operations. When you are redeploying an application you are trying to get rid of the previous classloader referencing all the previously loaded classes and replace it with a classloader loading new versions of the classes. Unfortunately many libraries used within applications make it impossible to throw away the old classloader which means that during each redeploy all the previous versions of your classes will still reside in PermGen and consume the memory.		Most often such errors are triggered during the redeploy operations. When you are redeploying an application you are trying to get rid of the previous classloader referencing all the previously loaded classes and replace it with a classloader loading new versions of the classes. Unfortunately many libraries used within applications make it impossible to throw away the old classloader which means that during each redeploy all the previous versions of your classes will still reside in PermGen and consume the memory.

	==~~======== <span id="anchor-2"></span>~~Examples of java.lang.OutOfMemoryError ~~========~~==		== Examples of java.lang.OutOfMemoryError ==

	~~========== <span id="anchor-3"></span>~~Trivial example ~~==========~~		'''Trivial example '''

	As seen in the causation section, PermGen space usage is strongly correlated with the number of classes loaded into the JVM. The following code serves as the most straightforward example:		As seen in the causation section, PermGen space usage is strongly correlated with the number of classes loaded into the JVM. The following code serves as the most straightforward example:

	<~~br /~~>		<syntaxhighlight lang="java">
	import javassist.ClassPool;~~<br />~~		import javassist.ClassPool;
	~~<br />~~
	~~public class MicroGenerator {<br />~~
	~~<br />~~
	~~public static void main(String[] args) throws Exception {<br />~~
	~~for (int i = 0; i < 100_000_000; i++) {<br />~~
	~~generate("eu.plumbr.demo.Generated" + i);<br />~~
	~~}<br />~~
	~~}<br />~~
	~~<br />~~
	~~public static Class generate(String name) throws Exception {<br />~~
	~~ClassPool pool = ClassPool.getDefault();<br />~~
	~~return pool.makeClass(name).toClass();<br />~~
	~~}<br />~~
	~~}<br />~~
	~~<br />~~

			public class MicroGenerator {

			public static void main(String[] args) throws Exception {
			for (int i = 0; i < 100_000_000; i++) {
			generate("eu.plumbr.demo.Generated" + i);
			}
			}

			public static Class generate(String name) throws Exception {
			ClassPool pool = ClassPool.getDefault();
			return pool.makeClass(name).toClass();
			}
			}
			</syntaxhighlight>

	In this example the source code is iterating over a loop and generating classes at the runtime. Class generation complexity is taken care by the [http://www.csg.ci.i.u-tokyo.ac.jp/~chiba/javassist/ javassist] library.		In this example the source code is iterating over a loop and generating classes at the runtime. Class generation complexity is taken care by the [http://www.csg.ci.i.u-tokyo.ac.jp/~chiba/javassist/ javassist] library.

	Launching the code above will keep generating new classes and loading their definitions in Permgen space until the space is fully utilized and the ~~“''java~~.lang.OutOfMemoryError: Permgen ~~space''”~~ is thrown.		Launching the code above will keep generating new classes and loading their definitions in Permgen space until the space is fully utilized and the “java.lang.OutOfMemoryError: Permgen space” is thrown.


	~~========== <span id="anchor-4"></span>~~Realistic example ~~==========~~		''' Realistic example '''

	As bit more complex and more realistic example, I demonstrate to you a''“java.lang.OutOfMemoryError: Permgen space”'' error occurring during a redeploy. To reproduce this error yourself, [http://portal.plumbr.eu/ download~~][http://portal.plumbr.eu/ ][http://portal.plumbr.eu/~~ a~~][http://portal.plumbr.eu/ ][http://portal.plumbr.eu/~~ demo~~][http://portal.plumbr.eu/ ][http://portal.plumbr.eu/~~ application] bundled with Plumbr, a memory leak detector tool. When running the demo application and attempting a redeploy with Plumbr attached, [http://plumbr.eu/ Plumbr] will find a memory leak, similar to the following:		As bit more complex and more realistic example, I demonstrate to you a “java.lang.OutOfMemoryError: Permgen space” error occurring during a redeploy. To reproduce this error yourself, [http://portal.plumbr.eu/ download a demo application] bundled with Plumbr, a memory leak detector tool. When running the demo application and attempting a redeploy with Plumbr attached, [http://plumbr.eu/ Plumbr] will find a memory leak, similar to the following:

			[[File:leak_velocity.png]]


Zeile 133:		Zeile 134:
	As a result, a ''jdbcDriver'' object holds a reference to ''org.hsqldb.jdbcDriver'' class which in turn holds reference to the instance of ''java.lang.Classloader'' used to load the application. And that'''ClassLoader still references all classes of the application. In case of this particular demo application, almost 2000 classes are loaded during application startup. These occupy roughly 12MB''' in PermGen. Which means that it would take about seven redeploys to fill PermGen and get the “''java.lang.OutOfMemoryError: PermGen space''” error message in your logs.		As a result, a ''jdbcDriver'' object holds a reference to ''org.hsqldb.jdbcDriver'' class which in turn holds reference to the instance of ''java.lang.Classloader'' used to load the application. And that'''ClassLoader still references all classes of the application. In case of this particular demo application, almost 2000 classes are loaded during application startup. These occupy roughly 12MB''' in PermGen. Which means that it would take about seven redeploys to fill PermGen and get the “''java.lang.OutOfMemoryError: PermGen space''” error message in your logs.

	==~~======== <span id="anchor-5"></span>~~Solution for java.lang.OutOfMemoryError ~~========~~==
			== Solution for java.lang.OutOfMemoryError ==

	The first solution to the OutOfMemoryError due to PermGen should be obvious. If we have exhausted the PermGen area in the memory we need to increase its size. This solution is indeed helpful if you just have not given your JVM enough elbow room. So alter your application launch configuration and add (or increase if present) the following:		The first solution to the OutOfMemoryError due to PermGen should be obvious. If we have exhausted the PermGen area in the memory we need to increase its size. This solution is indeed helpful if you just have not given your JVM enough elbow room. So alter your application launch configuration and add (or increase if present) the following:

Jochen: /* Cause of java.lang.OutOfMemoryError */

2016-09-29T20:21:21Z

Cause of java.lang.OutOfMemoryError

← Nächstältere Version		Version vom 29. September 2016, 22:21 Uhr
Zeile 77:		Zeile 77:
	== Cause of java.lang.OutOfMemoryError ==		== Cause of java.lang.OutOfMemoryError ==

	To understand the cause for the ~~“''java~~.lang.OutOfMemoryError: PermGen ~~space''“~~, we need to start by reminding that everything in Java is represented as an Object. Also, all objects are instances from a specific Class. Even the Class declarations themselves are ultimately just very specific Objects. But what makes the class declarations interesting is the fact that on most JVMs ~~'''~~Class declarations are loaded into a specific memory region, named Permanent Generation~~'''~~ (PermGen for short).So – to recap: all Java classes are loaded and stored in the Java PermGen. This consists of the following:		To understand the cause for the “java.lang.OutOfMemoryError: PermGen space“, we need to start by reminding that everything in Java is represented as an Object. Also, all objects are instances from a specific Class. Even the Class declarations themselves are ultimately just very specific Objects. But what makes the class declarations interesting is the fact that on most JVMs Class declarations are loaded into a specific memory region, named Permanent Generation (PermGen for short).So – to recap: all Java classes are loaded and stored in the Java PermGen. This consists of the following:

	* Names of the classes		* Names of the classes
Zeile 88:		Zeile 88:
	That’s pretty much it. Some more bits and pieces but it does not impact the actual memory consumption by more than few percent. All of these are allocated to PermGen and stay in PermGen.		That’s pretty much it. Some more bits and pieces but it does not impact the actual memory consumption by more than few percent. All of these are allocated to PermGen and stay in PermGen.

	As you can see, the PermGen size requirements depend both upon the number of classes loaded as well as the size of such class declarations. So it is easy to see the ~~'''~~main cause for the ~~“''''''''java''''''~~.~~''''''~~lang~~''''''~~.~~''''''~~OutOfMemoryError~~''''''~~: ~~''''''~~PermGen~~'''''' ''''''space''''''''“~~: either too many classes or too big classes are being loaded to the permanent generation~~'''~~.		As you can see, the PermGen size requirements depend both upon the number of classes loaded as well as the size of such class declarations. So it is easy to see the main cause for the “java.lang.OutOfMemoryError: PermGen space“: either too many classes or too big classes are being loaded to the permanent generation.

	Most often such errors are triggered during the redeploy operations. When you are redeploying an application you are trying to get rid of the previous classloader referencing all the previously loaded classes and replace it with a classloader loading new versions of the classes. Unfortunately many libraries used within applications make it impossible to throw away the old classloader which means that during each redeploy all the previous versions of your classes will still reside in PermGen and consume the memory.		Most often such errors are triggered during the redeploy operations. When you are redeploying an application you are trying to get rid of the previous classloader referencing all the previously loaded classes and replace it with a classloader loading new versions of the classes. Unfortunately many libraries used within applications make it impossible to throw away the old classloader which means that during each redeploy all the previous versions of your classes will still reside in PermGen and consume the memory.

Jochen am 29. September 2016 um 20:18 Uhr

2016-09-29T20:18:25Z

Änderungen zeigen