JVM memory tuning for a Java swing desktop application

Background introduction

Using java swing (jdk 1.7.0_71) to develop a desktop product similar to windows explorer, in addition to common functions such as file management, it also comes with a tag (TAG) management function, that is, to specify tags for files or folders, Manage files according to tags.

problems encountered

In the application, there is a function to search files based on keywords. There is no problem in the search itself, but when the screen displays the files or folders that meet the search conditions, the jvm memory is full. Because the test is an extreme In the case of , find all the files and folders with the a keyword under the C drive, because the result set is very large, so the JVM memory is full when the screen is displayed.

Cause Analysis

When the result set is displayed, it is actually adding new files to the JPanel. There are at least two JLabels in a file JPanel, one is used to display the icon, and the other is used to display the file name. The JVM heap is surging, and these objects will not be reclaimed by the JVM before switching to another screen. This causes the JVM memory to be full.

The whole process is as follows:

1> The default configuration starts java, the maximum heap memory is 247.5M, this value is absolutely not enough

because

NewRatio=2 default

SurvivorRatio=8 default

Eden space=64M

Survivor space=8M

Tenured gen=175.5M

The final result is as follows:

Console error:

Exception in thread "RMI TCP Connection(idle)" Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space

Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space

Exception in thread "JMX server connection timeout 23" java.lang.OutOfMemoryError: Java heap space

java.lang.NullPointerException

at sun.awt.SunToolkit.postEvent(SunToolkit.java:473)

at sun.awt.windows.WComponentPeer.postEvent(WComponentPeer.java:849)

2> Adjust the maximum heap memory to the upper limit of 1024M

-XX:+PrintGCDetails -Xms1024m -Xmx1024m

The actual heap total obtained: 990M

because

NewRatio=2 default

SurvivorRatio=8 default

Eden space=273M

Survivor space=34M

Tenured gen=683M

In the end, the search operation was successfully performed, but it was only reluctant (only 1K remained in Tenured gen)

The result is as follows:

3> From the results of 2>, it can be seen that the key to the problem is the size of the Tenured gen. Allocating the space to the Tenured gen as much as possible is the key to solving the problem. Therefore, we can add the -XX:NewRatio parameter to increase the Tenured gen space, such as:

-XX:+PrintGCDetails -Xms1024m -Xmx1024m -XX:NewRatio=4

Because most objects cannot be recycled, in order to reduce the gc time, we can actually remove the Survivor space in disguise by increasing the value of -XX:SurvivorRatio, for example:

-XX:+PrintGCDetails -Xms1024m -Xmx1024m -XX:NewRatio=4 -XX:SurvivorRatio=65536

4> The gc used before is a single-threaded serial collector, which is more suitable for a single machine. If you want to try the CMS concurrent collector, it is also possible, although it is not necessary.

-XX:+PrintGCDetails

-Xms1024m -Xmx1024m

-Xmn200m directly specifies the size of the young generation, which can also be adjusted by -XX:NewRatio

-XX:SurvivorRatio=65536 Remove Survivor space in disguise

-XX:+UseConcMarkSweepGC use CMS memory collection

-XX:ReservedCodeCacheSize=10m to save space as much as possible

-XX:MaxPermSize=20m to save space as much as possible

-XX:+CMSScavengeBeforeRemark Force a minor gc to start before remark to reduce the pause time of remark, but we don't need to add it in this case, because most objects will not be dropped by gc

-XX:+UseCMSInitiatingOccupancyOnly In order to cooperate with CMSInitiatingOccupancyFraction, if not specified, jvm will automatically determine when to perform gc based on historical data

-XX:CMSInitiatingOccupancyFraction=95 Tenured gen generation uses 95% space to perform gc