2016-12-12 2 views
0

Я анализировал кучу кучи из-за недавней сообщенной медлительности. Оказывается, есть пара массивов в 1,5 Гбайт байт, которые поселяются там, и я не могу отследить, откуда они взялись. MAT Eclipse не показывает мне класс, который держит такой огромный кусок. Он просто говорит «< системный загрузчик классов >». Возможно, я не смотрю в нужное место.Почему моя программа содержит 1,5 ГБ памяти в массиве байтов?

enter image description here

Что может быть причиной этих двух массивных байтовые массивы держат там? Приложение работает на сервере приложений Websphere. . Вот некоторые JVM Информация об окружающей среде я бегу приложение в Спасибо

  • Составлено в: JVM 1.6
  • среда Java версия: JRE 1.7.0 Linux amd64-64 построить 20130421_145945 (pxa6470sr4fp1ifix-20130423_02 (SR4 FP1 + IV38579 + IV38399 + IV40208))
  • Виртуальная машина версия: VM строить R26_Java726_SR4_FP1_2_20130421_2353_B145945
    Just-In-Time (JIT) компилятор переключатель, вперед-Of-Time (AOT) ключа компилятора, компилятора версии: r11.b03_20130131_32403ifx4
  • Исполнение сборщика мусора: GC - R26_Java726_SR4_FP1_2_20130421_2353 _B145945_CMPRSS
  • Java Heap Информация
    • -Xmx (максимальный размер кучи Java): 4096m
    • -Xms (Начальный размер Java кучи): 1024M
    • -Xscmx (Java совместное использование данных класса размер кэша): 90M
    • -Xscmaxaot (Максимальное число байтов в кэше, которые могут быть использованы для данных АОТ): 4М

Редактировать:

Эти два экземпляра массива байтов не определены непосредственно в моем коде. Тем не менее, я использую эти методы постоянно, в рамках класса util, чтобы читать и записывать массовые файлы начисления заработной платы. Интересно, имеет ли какое-то отношение к постоянному созданию временных файлов и входных потоков.

public abstract class IOUtils { 
public static Logger log = LoggerFactory.getLogger(IOUtils.class); 
private IOUtils() {} 
public static String readFirstLine(File f) { 
    String line = null; 
    BufferedReader reader = null; 
    try { 
     reader = new BufferedReader(new FileReader(f)); 

     line = reader.readLine(); 
    } catch (IOException e) { 
     log.warn("error reading header", e); 
    } finally { 
     if (reader != null) { 
      try { 
       reader.close(); 
      } catch (IOException e) { 
       log.warn("error closing file", e); 
      } 
     } 
    } 
    return line; 

} 


public static File multipartFileToFile(MultipartFile mFile) throws IOException { 
    File convFile = File.createTempFile(mFile.getOriginalFilename(), ".tmp"); 
    convFile.createNewFile(); 
    org.apache.commons.io.IOUtils.copy(mFile.getInputStream(), new FileOutputStream(convFile)); 
    return convFile; 
} 

public static File multipartFileToFile(MultipartFile mFile, String suffix) throws IOException, IllegalStateException { 
    File tmpFile = File.createTempFile(mFile.getOriginalFilename(), suffix); 
    mFile.transferTo(tmpFile); 

    return tmpFile; 
} 


public static byte[] readBytes(File file) throws IOException { 
    return org.apache.commons.io.IOUtils.toByteArray(new FileInputStream(file), file.length()); 
} 


public static void writeBytes(File file, byte[] data) throws IOException { 
    org.apache.commons.io.IOUtils.write(data, new FileOutputStream(file)); 
} 

}

+0

У вас есть какие-то смехотворно большие статические поля? –

+0

Ничего необычного. Просто обычные строковые константы, редко более 70 символов. – Razorblade

ответ

1

Это почти невозможно дать четкий ответ, так как вы не предоставили никакой полезной информации, такой как код.

Сборщик мусора Java в конечном итоге освободит память, если на нем нет ссылок. Попробуйте установить массив равным нулю и убедитесь, что нет функций, классов или потоков, которые каким-то образом поддерживают ссылку на нежелательную память.

+0

Я только что обновил сообщение с помощью некоторого кода, который я использую постоянно, что может вызвать утечку памяти. – Razorblade

+1

@Razorblade убедитесь, что все читатели и писатели файлов закрыты. Оператор 'using' хорош для обеспечения надлежащего выпуска ресурсов. Также избегайте статической методологии, если можете. –

+0

Последняя вещь @JakePsimos: Несмотря на то, что приложение работает в JDK 7, которое, как известно, автоматически закрывает их, оно скомпилировано в JDK 6. Будет ли они все еще закрываться автоматически? Я возьму ваш совет, хотя, это всего лишь пара строк для хорошей причины :) спасибо – Razorblade

0

Попробуйте использовать JVisualVM для отслеживания того, из какого класса возникает проблема кучи.

Смежные вопросы