Утечки памяти Oracle T4CPreparedStatement?

Немного фона на приложении, что я собираюсь говорить о в следующих нескольких строках:

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.

Так, мои вопросы здесь:

  1. Вы когда-либо сталкивались с проблемой как это?
  2. Вы знаете значение lastBoundChars / bindChars?
  3. Я плохо знаком с профилированием, Вы думаете, что я не делаю его корректный? (Я также выполнил hprofs через ЦИНОВКУ - и это было основной определенной проблемой - так, я действительно не думаю, что мог быть неправым?)

Я нашел что-то подобным в сети здесь: http://forums.oracle.com/forums/thread.jspa?messageID=2860681

Цените свои предложения / совет.

5
задан Jay 20 May 2010 в 20:22
поделиться

1 ответ

Хотя это возможно, кажется маловероятным, что вы обнаружили огромную утечку памяти в 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
}
9
ответ дан 18 December 2019 в 06:34
поделиться
Другие вопросы по тегам:

Похожие вопросы: