Why does the memory usage increase when I redeploy a web application?

That is because your web application has a memory leak.

A common issue are "PermGen" memory leaks. They happen because the Classloader (and the Class objects it loaded) cannot be recycled

unless some requirements are met (*). They are stored in the permanent heap generation by the JVM, and when you redeploy a new class

loader is created, which loads another copy of all these classes. This can cause OufOfMemoryErrors eventually.

(*) The requirement is that all classes loaded by this classloader should be able to be gc'ed at the same time.

To avoid memory leaks, you need to pay attention to how you write your code. Here are specific methods to help you stamp out memory leaks.

Using the java.lang.ref package, you can work with the garbage collector in your program. This allows you to avoid directly referencing objects,

but use special reference objects that are easily cleared by the garbage collector. The special subclasses allow you to refer to objects indirectly.

For instance, Reference has three subclasses: PhantomReference, SoftReference, and WeakReference.

A referent, or an object that is referenced by these subclasses, can be accessed using that reference object’s get method. The advantage of

using this method is that you can clear a reference easily by setting it to null and that the reference is pretty much immutable, or it cannot be

changed. How does garbage collector act with each type of referent?

SoftReference object: Garbage collector is required to clear all SoftReference objects when memory runs low.
WeakReference object: When garbage collector senses a weakly referenced object, all references to it are cleared and ultimately taken out of memory.
PhantomReference object: Garbage collector would not be able to automatically clean up PhantomReference objects, you would need to clean it up manually by clearing all references to it.

Using reference objects, you can work with the garbage collector to automate the task of removing listeners that are weakly reachable.

WeakReference objects, especially with a cleanup thread, can help you avoid memory errors.

If you are using Jetty 7.6.6. or higher, you can prevent WebApp classloader pinning. When your code keeps referring to a webapp classloader,

memory leaks can easily happen. There are two types of leaks in this case: daemon threads and static fields.

Static fields are started with the classloader’s value. Even as Jetty stops deploying and then redeploys your webapp, the static reference persists and so the object cannot be cleared from memory.
Daemon threads that are started outside the lifecycle of a Web application are prone to memory leaks because these threads have references to the classloader that started the threads.

出处：

tomcat wiki:

其他博客：