And yet it is so simple to do those improvements while developing applications. One of them is not to use import package.*; and only include the packages you really need. This may sound so simple but I doubt many people think about this when developing applications. I have often heard (and yes i have done that mistake myself recently) people say stuff like “I cant be bothered with every single include, i rather just include everything” and “It doesnt really matter”.

And to be all honest – it is true when developing small applicationsm that do not require to be run for a very long time without destroying the VM (a.k.a restarting the application). But in the long run – the more classes you are importing, the more PermGen memory is used — and that is a waste when you do not need so many classes.

So here is a first and really basic optimization suggestion:

Try avoiding importing * packages as much as possible. I do realize that it may not always be easy to do and your code may become a few hundered lines larger — but in the long run you will not regret it!

Now a fast numbers to prove my point

Unoptimized application PermGen usage:14.5Mb With the following * imports:

import java.util.*;
import java.io.*;
import java.sql.*;

Optimized application PermGen usage: 10.2Mb When replaced * imports with in somewhat 30 classes:

import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileWriter;
import java.io.IOException;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Timestamp;
import java.util.Date;
import java.util.Iterator;
import java.util.Vector;

As you can see numbers speak for themselves – that is quite an optimization

VisualVM has made it a bit easier for us to monitor remote apps. You will have to start jstatd process on your remote system and then you can monitor how your remote VM is feeling.

However.. there are some pitfalls. Here are 2 of the most annoying once:

When starting jstatd you are getting Security Exceptions

To solve this error you will need to create a policy file containing something like this (call it jstatd.all.policy):

grant codebase "file:${java.home}/../lib/tools.jar" {

permission java.security.AllPermission;

};

Now start jstatd with the following command:

jstatd -J-Djava.security.policy=jstatd.all.policy

You are trying to connect to the remote host but getting Socket connection refused.

This is most likely caused because of an underlying exception – connection refused to host 127.0.0.1 or something simmilar (not the IP you are trying to access). This is easily solved by adding the following parameter to jstatd startup command:

-J-Djava.rmi.server.hostname=<your ip or hostname>

… Naturally there are more pitfalls but I am not going to cover all of them here. VirtualVM, just like legacy jConsole may be very usefull for monitoring how some applications act in the testing environment before you put them into producstion. Usually things that do not appear on your development machine while profiling may appear in the test environment where it is hard to notice them without profiling.

One of such problems may be MySQL Connector/J PermGen leak caused by Statement cancelation timer (something i have encountered recently and trying to come around)