Когда собрать "мусор"
Вы могли сделать это со статическим импортом и классом
nb помощника, generification этого класса мог, вероятно, быть улучшен
public class Lists {
private Lists() { } // can't be instantiated
public static List<T> join(List<T>... lists) {
List<T> result = new ArrayList<T>();
for(List<T> list : lists) {
result.addAll(list);
}
return results;
}
}
Тогда, можно сделать вещи как
import static Lists.join;
List<T> result = join(list1, list2, list3, list4);
8 ответов
Удалось ли вам улучшить производительность с помощью System.gc ()? Я так не думаю, поскольку у вас, вероятно, не так много объектов, которые нужно собрать перед загрузкой изображения.
Обычно современные сборщики мусора лучше знают, когда запускать, поэтому вы не должны форсировать сборку, если у вас нет действительно действительно хорошая причина. (например, приложение для тестирования производительности, предложенное этим плагином)
btw: Вызов System.gc () рекомендует виртуальной машине выполнить «полный» или «большой» сбор данных, что означает, что все потоки будут вскоре остановлены. В противном случае он, вероятно, будет делать только «маленькие» сборки мусора, которые не останавливают все потоки.
Запустите вашу программу с -verbose: gc, чтобы узнать, сколько байтов было собрано.
Также есть много технической информации по сборка мусора здесь: http://java.sun.com/developer/technicalArticles/Programming/GCPortal/
Обычно сборщик мусора умнее вас, поэтому лучше позволить ему работать, когда это решит среда выполнения. Если среде выполнения требуется память, она запустит сам сборщик мусора
Вызывать сборщик мусора - это нормально, никаких «проблем» с ним не возникает. Однако я сомневаюсь, что это значительно повысит производительность, если этот вызов также не касается дефрагментации выделенных данных. Я этого не знаю.
В этом случае вам следует профилировать код. Запустите его несколько раз и посмотрите, какие результаты вы получите.
Вы уже получили много хороших советов, которые я постараюсь не повторять.
Если у вас действительно возникают проблемы с GC, например, полная остановка вашего приложения на секунду, сделайте следующее: 1. убедитесь, что нет никаких вызовов System.gc (); 2. Ознакомьтесь с различными вариантами настройки gc. Таких много, и они гораздо более полезны, чем принуждение gc.
Обычно вы не должны вмешиваться в работу сборщика мусора. Если перед загрузкой образа необходимо освободить некоторую память, сборщик мусора сделает это за вас.
В любом случае, если вы делаете это только один раз, это, вероятно, не сильно повлияет на вашу производительность. Циклы выполнения намного важнее.
Убедитесь, что большие объекты можно установить как можно раньше. Т.е. установить переменные в ноль и / или позволить им выпасть из области видимости. Это помогает!
В случае сбоя выделения памяти запускается цикл GC и повторная попытка выделения.
Как правило, нет. Вызывать System.gc () нецелесообразно. Однако у меня было несколько случаев, когда это имело смысл.
В программном обеспечении, которое я пишу, есть встроенный уровень отслеживания производительности. Он в основном используется во время автоматизированного тестирования, но может использоваться в полевых условиях для диагностических целей. Между тестами или после определенных запусков мы несколько раз вызовем System.gc, а затем запишем память, которая все еще присутствует. Он предоставляет нам базовый тест производительности памяти для отслеживания линий тренда потребления памяти с течением времени. Хотя это можно сделать с помощью некоторых внешних интерфейсов JVM, это было проще сделать на месте, и точное количество не требовалось.
В гораздо более старой системе у нас могло быть до 72 отдельных JVM (да, 72, на то была веская причина во время постройки). В этой системе оставление кучи в свободном плавании на всех 72 JVM может привести к чрезмерному (намного превышающему физическую память) общему потреблению памяти. System.gc () вызывался между интенсивными упражнениями с данными, чтобы попытаться сохранить JVM ближе к среднему, чтобы не допустить роста кучи (ограничение кучи могло быть другим направлением, но тогда разработчикам потребовалось бы настроить больше для каждого сайта и лучше знать, что происходило под капотом, чтобы все было правильно и не допустить сбоя системы под нагрузкой).