Как предотвратить утечки памяти на этапе проектирования компонента?

Question

Я работаю над веб-компонентом, который будет разработан на Java.Часть этого основана на веб-сервисах, в то время как другая имеет среду Spring-MVC и Hibernate для персистентного слоя.

Я все еще нахожусь в процессе проектирования - готовлю сценарии использования, диаграммы активности и последовательности.

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

Answer 1

Наибольшее количество утечек памяти происходит из-за сбоев в реализации, в Java большинство основано на недостаточном понимании используемой технологии.(например, 4 различных вида внутренних классов)

Единственный способ, который помогает здесь, это тратить время и деньги на навыки разработчиков.- Лучшее чтение Effective Java Second Edition Джошуа Блоха

Другая область, которая часто вызывает утечки памяти, - это параллелизм.- Насколько мне известно, лучший способ справиться с этим (и другими проблемами параллелизма) состоит в том, чтобы определить, какие компоненты должны быть сохранены (и какие выполняются в среде с одним потоком) ПЕРЕД их реализацией.И если они должны быть реализованы с сохранением потоков, то определите ДО того, как ТОЛЬКО реализуете, ЧТО ТОЛЬКО они гарантируют, что они сохранят потоки (какие функции и методы защищены чем).

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

Еще одна мысль, которую вы можете сделать по своему замыслу, - это создать сторожевой таймер.Если у вас есть (например) динамический список, где нет большой проблемы, когда некоторые элементы списка теряются, и вы знаете, что список может быть причиной некоторых проблем (сбои в потоке или реализации), тогда реализуйтесторожевой таймер, который очищает список, если он становится намного больше, чем вы ожидаете.(А затем: исправьте ошибку, которая вызывает проблему!) - Примером такого списка может быть список событий обновления GUI фондовой биржи (на не относящемся к акции веб-сайте).Если одно обновление курса отправляется не клиенту, а следующему (одна секунда спустя), то потеря одного обновления намного лучше, чем сбой всего сервера.

Answer 2

Одним из наиболее распространенных случаев утечки памяти в Java является кеширование:

Map<String, Connection> userConnection = new HashMap<String, Connection>();
// cache connections:
userConnection.put("User X", connectionInstance);
// connectionInstance is closed but never the userConnection.remove("User X") is called.

Когда соединение закрыто, это сопоставление не очищается из-за утечки памяти.

Отвечая на ваш вопрос, поместите в свои строки, чтобы использовать WeakHashMap (http://download.oracle.com/javase/6/docs/api/java/util/WeakHashMap.html) для кэширования, а не использовать "обычный" HashMap.

Answer 3

Загрузка системы - это только половина проблемы при обнаружении утечек ресурсов. Вторая проблема заключается в наличии надлежащей системы мониторов и диагностических утилит, чтобы понять, как используются ресурсы и как они могут быть затронуты.

В конечном итоге утечки ресурсов на самом деле делятся на четыре широкие категории: память, диск, сеть и процессор. Если вы просматриваете код своего приложения, гостевую операционную систему, такую ​​как Java или базу данных, или основную операционную систему, все метрики, которые вы можете собрать, являются подмножеством этих элементов.

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

Если вам нужна легкая глубокая диагностика, которая может помочь профилировать весь путь обратно к этапам модульного тестирования и сборки компонентов, а затем использовать одни и те же инструменты в процессе тестирования производительности, тогда я могу порекомендовать решения из этого организация, http://www.rtiperformance.com/.

Джеймс Пулли

Модератор: SQAForums Loadrunner | WinRunner, GoogleGroups lr-loadrunner, YahooGroups LoadRunner | Advanced-LoadRunner, LinkedIn LoadRunner (владелец) | LoadRunnerbyTheHour (владелец)

Answer 4

Я не верю, что вы можете предотвратить утечки памяти на этапе проектирования.Однако использование традиционных инструментов нагрузочного тестирования, таких как JMeter / Grinder / Loadrunner и т. Д., Может помочь обнаружить утечки памяти, чтобы их можно было исправить перед выпуском.

Тестирование производительности должно быть включено на каждом этапе процесса разработки, так же как и в модулетестирование и интеграционное тестирование.

Answer 5

Вы должны беспокоиться не только о памяти.Также необходимо учитывать такие ресурсы, как многопоточность, файлы и сетевые подключения.

Я могу порекомендовать вам прочитать книгу Архитектура программного обеспечения на основе шаблонов, том 3: Шаблоны для управления ресурсами .Он содержит несколько полезных шаблонов для рассмотрения.