Немного фона на приложении, что я собираюсь говорить о в следующих нескольких строках:
XYZ является данными, маскирующими приложение RCP затмения инструментальных средств: Вы даете ему столбец исходной таблицы и целевой столбец таблицы, это применило бы trasformation (шифрование/перестановка/и т.д.) и скопировало бы данные строки из исходной таблицы для предназначения для таблицы. Теперь, когда я маскирую n таблицы за один раз, n потоки запускаются этим приложением.
Вот проблема:
Я столкнулся с производственной проблемой о первом списке из вышеупомянутого приложения. К сожалению, у меня нет журналов для получения до корня. Однако я пытался запустить это приложение в тестовом регионе и сделать стресс-тест.
Когда я собрал .hprof файлы и выполнил их через анализатор (yourKit), я заметил это объекты oracle.jdbc.driver. T4CPreparedStatement сохраняли "кучу". Анализ также говорит мне, что один из моих классов содержит ссылку на этот объект preparedstatement и таким образом, n потоки имеют n такие объекты. T4CPreparedStatement, казалось, имел символьные массивы: lastBoundChars и bindChars каждый символ размера [300000].
Так, я исследовал немного (Google!), полученный ojdbc6.jar и попробованная декомпиляция T4CPreparedStatement. Я вижу, что T4CPreparedStatement расширяет OraclePreparedStatement, который динамично управляет размером массива lastBoundChars и bindChars.
Так, мои вопросы здесь:
Я нашел что-то подобным в сети здесь: http://forums.oracle.com/forums/thread.jspa?messageID=2860681
Цените свои предложения / совет.
Хотя это возможно, кажется маловероятным, что вы обнаружили огромную утечку памяти в 11g. Я бы начал с получения фактического SQL из просочившихся курсоров и поиска в коде того, где этот SQL создается. Очень частой причиной утечки курсоров, которую я обнаруживал в прошлом, является такой код:
try {
PreparedStatment stmt = null;
stmt = con.prepareStatement("SOME AWESOME SQL");
//lots of lines of code that masks the problem
stmt = con.prepareStatment("DIFFERENT SQL"); //You just leaked "SOME AWESOME SQL"!!!
//lots more code
} finally {
stmt.close() //looks like everything is ok, but only the second one actually got closed
}