Почему прокрутка JTable занимает столько памяти?

Question

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

Всякий раз, когда я прокручиваю JTable, требуется около 8 М памяти ... Есть ли способ, как исправить это? Он останавливается каждый раз после использования 40-60 МБ памяти. Является ли это проблемой Swing?

Благодарим за ответы.

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

Я пытался понять, почему это занимает так много памяти. Теперь я знаю источник проблемы. Я сделал небольшую кнопку с этим действием. Преобразовано: jScrollPane1.repaint();.

Когда я ударил его 10 раз, я получил большие объемы памяти в диспетчере задач, а также в VisualVM. Но в VisualVM GC начинает собираться на 50 МБ и снижает его до 8 Мб. Но диспетчер окон все еще увеличивает свою ценность.

Метод перерисовки делает большие утечки памяти в окнах. Есть ли какие-либо исправления?

Edit2

Дальнейшее исследование этой проблемы дал мне это. Я попытался запустить эту программу на платформе Linux без утечки. В программе было использовано около 20 М памяти. Поэтому я запрограммировал небольшой поток, который вызывал метод перерисовки как на JScrollPanes. И, к моему удивлению, в Windows память машины росла до 110 М, но затем ОС начала сильно напрягаться по памяти.

Нить:

@Override 
public void run() { 
     while (true) { 
      jScrollPane1.repaint(); 
      jScrollPane2.repaint(); 
      try { 
       this.sleep(10); 
      } catch (InterruptedException ex) { 
       ex.printStackTrace(); 
      } 
     } 
    } 

я делал нормальную копию/переименовывать/удалять операции также происходит через каталоги, с память не растет. Я заметил, что память также уменьшалась до 99M.

На резьбе мониторинга:

@Override 
public void run() { 
    while (true) { 
     aLabel.setText("Memory consumption: " + (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()); 
     try { 
      this.sleep(200); 
     } catch (InterruptedException ex) { 
      ex.printStackTrace(); 
     } 
    } 
} 

номера были от 8М до 50М, а затем снова 8M. Поэтому сбор мусора был успешным. Итак, реальной проблемой является платформа Windows или совместимость JVM? Как trashgod предположил, что диспетчер задач не точен в получении потребления памяти, но память действительно используется процессом java.

Answer 1

Повторное использование FileSystemView.getFileSystemView() может быть проблемой, как предложено here и профилировано here. Это может помочь изменить ваш вопрос, чтобы включить sscce, который демонстрирует проблему. Использование профилировщика может предполагать масштаб и серьезность проблемы; Java VisualVM может быть уже установлен.

Менеджер задач Windows все еще увеличивает свою ценность.

Диспетчер задач Windows может быть несовместим, как предлагается here. В этом контексте результат jvisualvm может быть более надежным.

Answer 2

никогда не использовать Thread#sleep во время EDT, что причина, почему вы получите un_expecting UsedMemory,

1) GUI Качели однопоточен

2) Качели GUI ждет всех событий сделано, все изменения делаются на экране один момент, в том числе использование Thread#sleep,

3) с помощью Thread#sleep вы можете моделировать и увидеть на экране un_expected перерисовки графического интерфейса, или значение не обновляется или перекрасить

4) у вас есть проблемы с Concurency in Swing

5) Я не вижу никаких причин для использования repaint() там, обратите внимание, что очень трудно метод локальной среды

6) использовать и завернуть вам код в

• javax.swing.Timer

• SwingWorker

• Runnable@Thread

7), так как у меня есть несколько методов, когда требуется (намеренное) использование Thread#sleep, не простая работа без Controler покрыта весь EDT