Произойдет ли утечка ResultSet, если она явно не закрыта?

Я использую пул соединений JDBC с Jetty, имел эту настройку на экземпляре сервера без проблем в течение года. Я переключился на новый сервер Ubuntu, и у меня не хватает памяти. Я профилирую использование памяти и вижу следующие экземпляры высшего класса:

java.util.Hashtable$Entry (33%)
com.mysql.jdbc.ConnectionPropertiesImpl$BooleanConnectionProperty (13%)
com.mysql.jdbc.ConnectionPropertiesImpl$StringConnectionProperty (3%)
com.mysql.jdbc.ConnectionPropertiesImpl$IntegerConnectionProperty (3%)

Я не закрываю свои экземпляры ResultSet явно, я делаю что-то вроде:

Connection conn = null;
PreparedStatement stmt = null;
try {
    conn = ...;
    stmt = ...;
    ResultSet rs = ...;
    rs.useIt();
}
finally {
    if (stmt != null) { stmt.close(); }
    if (conn != null) { conn.close(); }
}

В документах говорится, что Statement закроет связанные экземпляры ResultSet, когда он закроется - возможно ли, что реализация jdbc на этом компьютере с Ubuntu на самом деле этого не делает? Я не внес никаких изменений в свой код (упакованный файл .war), я просто поместил его в экземпляр Jetty на этой машине с Ubuntu как есть.

Профилирование показывает, что экземпляры com.mysql.jdbc.ConnectionPropertiesImpl продолжают расти, поэтому можно предположить, что это именно то, что происходит.

Я просто хотел проверить, прежде чем уйти и изменить весь мой код, чтобы явно закрыть экземпляры ResultSet. Глядя на MySql Workbench, я не вижу ничего необычного в представлении Client Connections - мои соединения с приложениями входят и, похоже, очищаются нормально.

Спасибо

-------------------- Обновить --------------------

Я изменил все свои экземпляры ResultSet, чтобы закрыть их немедленно, а также в блоке finally {}, так же, как мои экземпляры Connection и PreparedStatement. Кажется, это не помогает, память продолжает расти.

Покопавшись еще немного, я заметил класс:

com.mysql.jdbc.JDBC4Connection

и количество экземпляров никогда не уменьшается. Примерно через 10 минут работы я вижу почти 5 тыс. Экземпляров (yikes?).

Этот пост выглядит очень похоже на то, с чем я сталкиваюсь:

Утечка памяти в JDBC4Connection

ОП говорит, в конце концов:

ORM полагался на закрытие соединения со свободными ресурсами в финализаторе (иногда на закрытие результирующих наборов и операторов), но пул оставлял соединения открытыми в течение нескольких часов, и в случае любого пика это вызывало OOM.

Я не понимаю, что это значит, или как можно это исправить. Я почти уверен, что теперь я везде закрываю свои ресурсы (в противном случае, когда я запускал одно и то же веб-приложение на другом сервере Windows, я тоже мог видеть утечку?).

-------------------- Обновить --------------------

Все еще видя такое же поведение, вот как я открываю соединение БД в каждом обрабатываемом запросе (проверка ошибок опущена):

 public class DsHelper {
    private static DsHelper sInstance;
    private DataSource mDs;

    public DsHelper() {
        InitialContext ctx = new InitialContext();
        mDs = (DataSource)ctx.lookup("java:comp/env/jdbc/myds");
    }

    public static DsHelper get() { 
        if (sInstance == null) {
            sInstance = new DsHelper();
        }

        return mInstance;
    }

    public DataSource getDataSource() {
        return mDs;
    }
}

используй это:

protected void doGet(HttpServletRequest request, 
                     HttpServletResponse response) 
{
    Connection conn = null; 
    try {
        conn = DsHelper.get().getDataSource();
        ...
    }
    finally {
        if (conn != null) { conn.close(); }
    }
}

Ответы на вопрос(2)

Ваш ответ на вопрос