Сколько памяти расходует мое приложение Java?

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

В начале 1970-х годов 1 МБ памяти стоил 1 миллион долларов. Теперь 1 МБ стоит в миллионы раз меньше. Это одна из причин, почему инженеры и предприятия больше не беспокоятся о памяти. Кстати, 1 миллион долларов в 1970-х годах - это эквивалент нескольких миллионов долларов сегодня. Вот почему память была так драгоценна в те дни. Автобиография Пола Аллена подробно рассматривает эту проблему. Пол Аллен рассказывает о трудностях, с которыми он и Билл Гейтс столкнулись при написании базовых программ менее чем в 4 КБ.

Однако, хватит истории. Есть 4 основных вычислительных ресурсов:

• ЦП
• Память
• Сеть
• Место хранения

Приложение может работать на десятках или даже тысячах экземпляров сервера приложений. Какой ресурс экземпляр приложения использует в первую очередь?

Для большинства приложений это память. Процессор всегда находится на уровне 30-60%. Всегда есть обильное хранилище. Трудно перезагрузить сеть (если только ваше приложение не работает с потоковым видео). Таким образом, для большинства приложений это память, которая переполняется в первую очередь. Несмотря на то, что процессор, диск и сеть недостаточно используются, вы в конечном итоге инициализируете все больше и больше экземпляров сервера приложений только потому, что память становится насыщенной. Это может увеличить вычислительные затраты для организаций до миллионов и миллиардов долларов.

С другой стороны, все без исключения современные приложения теряют от 30 до 90% памяти из – за неэффективных методов программирования. Ниже приведены девять различных методов, которые используются в промышленности, которые вызывают потерю памяти:

• Повторяющиеся строки
• Неэффективные коллекции
• Дублирование объектов
• Дублирование массивов
• Неэффективные массивы
• Объекты, ожидающие завершения
• Цифры в упаковке
• Накладные расходы, вызванные заголовками объектов
• Неверные настройки размера памяти

Если вы можете устранить эти 30-90% потерь памяти, это принесет два основных преимущества для вашего предприятия:

Снижение вычислительных затрат: поскольку память является первым ресурсом, который насыщается, если вы можете уменьшить потребление памяти, вы сможете запускать свое приложение на меньшем количестве экземпляров сервера. Вы могли бы быть в состоянии уменьшить 30-40% серверов. Таким образом, ваше руководство может сократить на 30-40% расходы на обслуживание и поддержку своего центра обработки данных (или облачного хостинг – провайдера). Только это может привести к экономии средств на несколько миллионов или миллиардов долларов.

Лучший опыт работы с клиентами: если вы уменьшаете количество объектов, которые вы создаете для обслуживания входящего запроса, ваше время отклика будет намного лучше. Поскольку создается меньше объектов, меньше циклов процессора тратится на создание и сборку мусора. Сокращение времени отклика улучшит опыт клиента.

Сколько памяти тратит мое приложение?

Итак, давайте вернемся к исходному вопросу этой статьи "сколько памяти расходует мое приложение?". Это печально, но верно: в отрасли не так много инструментов, которые могут дать вам этот ответ. Мы поможем вам ответить на этот вопрос в два простых шага.

Шаг 1: Захват дампов кучи

Для того, чтобы проанализировать, как память тратится впустую, вам сначала нужно захватить дамп кучи. Дамп кучи - это в основном снимок памяти вашего приложения. Он содержит информацию обо всех объектах, присутствующих в памяти, кто ссылается на него, и многое другое.

Существует несколько вариантов захвата дампов кучи из вашего приложения Java. Существует также несколько вариантов захвата кучи дампов из Android-приложений.

Вы должны использовать вариант, который лучше всего подходит для вас и ваших приложений.

Рекомендуется захватывать дамп кучи, когда приложение принимает трафик. Когда приложение простаивает, новые объекты не будут созданы, таким образом, вы не сможете увидеть, сколько памяти на самом деле тратится впустую.

Шаг 2: Анализ с помощью инструмента HeapHero

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

В зависимости от вашего приложения, дампы кучи могут содержать данные PII и другие конфиденциальные данные. В этом случае вы можете зарегистрироваться, чтобы загрузить и установить инструмент HeapHero локально на вашем компьютере.

Этот инструмент даст высокоуровневую сводку общего объема памяти, которая тратится впустую, фактические данные, которые вызывают потерю памяти, и строки кода, которые вызывают эту потерю памяти. Он даже рекомендует решения для устранения проблемы.



HeapHero создает круговую диаграмму, которая суммирует, сколько памяти тратится впустую из-за каждой неэффективной практики программирования. По-видимому, это приложение тратит 35% своей памяти. Две главные причины этой потери:

• Неэффективные коллекции (т. е. структуры данных) вызывают 11,5% потерь памяти.
• Дублирование строк вызывает 10,4% потерь памяти.

В этом приложении имеется 343 661 экземпляр строковых объектов. Из них только 144 520 являются уникальными. По-видимому, есть 6,147 случаев “webservices.sabre.com-строковые объекты. Почему так много дубликатов? Почему это не было очищено, чтобы освободить больше памяти?



В этом приложении 34% HashMap не содержит элементов. Это вызывает вопрос о том, почему так много хэш-карт были созданы без каких-либо элементов. При создании хэш-карты по умолчанию создается 16 элементов. Пространство, выделенное для этих 16 элементов, теряется, когда вы не вставляете в него никаких элементов. Интересно, что 97% Hashtable также не содержит никаких элементов.



В заключение

Этот инструмент от HeapHero не только показывает объекты, которые теряют память, но также показывает путь кода, который вызывает потерю памяти. Эти знания облегчат программистам нахождение того, что надо исправить в приложении.