Основные проблемы с памятью Java - История изменений

IKuznetsov в 16:16, 8 января 2025

2025-01-08T16:16:06Z

← Предыдущая версия		Версия от 16:16, 8 января 2025
Строка 1:		Строка 1:
	'''''[[Поддержка технологий]] / [[Java]] / Основные проблемы с памятью Java'''''		'''''[[Поддержка технологий]] / [https://docs.expert-apm.ru/index.php/%D0%9F%D0%BE%D0%B4%D0%B4%D0%B5%D1%80%D0%B6%D0%BA%D0%B0_%D1%82%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D0%B9#:~:text=%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B5%20%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D0%B5 Программное обеспечение] / [[Java]] / Основные проблемы с памятью Java'''''

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

IKuznetsov в 16:12, 8 января 2025

2025-01-08T16:12:25Z

← Предыдущая версия		Версия от 16:12, 8 января 2025
Строка 16:		Строка 16:
	Изменяемые статические поля и коллекции		Изменяемые статические поля и коллекции

	* Наиболее частая причина утечки памяти - неправильное использование статики. Статическая переменная хранится в ее классе, а затем в загрузчике классов. Хотя класс можно собирать мусором, это редко происходит в течение жизненного цикла приложения. Часто статика используется для хранения информации ~~кеша~~ или обмена состоянием между потоками. Если этого не делать прилежно, легко получить утечку памяти. По этой причине следует избегать статических изменяемых коллекций любой ценой. Хорошее архитектурное правило - вообще не использовать изменяемые статические объекты и довольствоваться лучшими альтернативами.		* Наиболее частая причина утечки памяти - неправильное использование статики. Статическая переменная хранится в ее классе, а затем в загрузчике классов. Хотя класс можно собирать мусором, это редко происходит в течение жизненного цикла приложения. Часто статика используется для хранения информации кэша или обмена состоянием между потоками. Если этого не делать прилежно, легко получить утечку памяти. По этой причине следует избегать статических изменяемых коллекций любой ценой. Хорошее архитектурное правило - вообще не использовать изменяемые статические объекты и довольствоваться лучшими альтернативами.

ENetrebin в 15:06, 15 августа 2023

2023-08-15T15:06:53Z

← Предыдущая версия		Версия от 15:06, 15 августа 2023
Строка 1:		Строка 1:
			'''''[[Поддержка технологий]] / [[Java]] / Основные проблемы с памятью Java'''''

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

IKolomin в 07:47, 1 декабря 2021

2021-12-01T07:47:53Z

← Предыдущая версия		Версия от 07:47, 1 декабря 2021
Строка 8:		Строка 8:
	Ниже приведены некоторые из причин утечки памяти:		Ниже приведены некоторые из причин утечки памяти:

	~~Thread local variables~~		Локальные переменные потока

	* ~~<code>~~ThreadLocal~~</code> variables are used to bind a variable or a state to a thread~~. ~~Each thread has its own instance of the variable~~. ~~While <code>~~ThreadLocal~~</code> variables can be useful~~, ~~they can also be dangerous~~. ~~They are used to track a state~~, ~~such as the current transaction ID~~, ~~but sometimes hold some more information~~. ~~A <code>~~ThreadLocal~~</code> variable is referenced by its thread and its lifecycle is bound to it~~. ~~In most application servers, threads are reused via thread pools and are never garbage collected~~. ~~If the application code does not carefully clear the <code>~~ThreadLocal~~</code> variable~~, ~~it results in a nasty memory leak~~. ~~Such leaks can be easily discovered with a heap dump by looking at the <code>~~ThreadLocalMap~~</code> and following the references~~. ~~In the above screen~~, ~~the heapdump indicates that over 4K objects~~, ~~which amount to around 10MB in size~~, ~~are held by <code>~~ThreadLocal~~</code> variables~~. ~~The name of the thread reveals the part of the application that is responsible for the leak~~.		* Переменные ThreadLocal используются для привязки переменной или состояния к потоку. У каждого потока есть собственный экземпляр переменной. Хотя переменные ThreadLocal могут быть полезны, они также могут быть опасными. Они используются для отслеживания состояния, например идентификатора текущей транзакции, но иногда содержат дополнительную информацию. На переменную ThreadLocal ссылается ее поток, и ее жизненный цикл привязан к ней. На большинстве серверов приложений потоки повторно используются через пулы потоков и никогда не собираются сборщиком мусора. Если код приложения не очищает переменную ThreadLocal тщательно, это приводит к неприятной утечке памяти. Такие утечки можно легко обнаружить с помощью дампа кучи, просмотрев ThreadLocalMap и следуя ссылкам. На приведенном выше экране heapdump указывает, что более 4К объектов, размер которых составляет около 10 МБ, удерживаются переменными ThreadLocal. Название потока показывает, какая часть приложения ответственна за утечку.

	~~Mutable static fields and collections~~		Изменяемые статические поля и коллекции

	* ~~The most common reason for a memory leak is the wrong usage of statics~~. ~~A static variable is held by its class and~~, ~~subsequently, by its classloader~~. ~~While a class can be garbage collected~~, ~~it will seldom happen during an application's lifetime~~. ~~Often, statics are used to hold cache information or share state across threads~~. ~~If this is not done diligently~~, ~~it is easy to get a memory leak~~. ~~For this reason, static mutable collections must be avoided at all costs~~. ~~A good architectural rule is to not use mutable static objects at all and settle for better alternatives~~.		* Наиболее частая причина утечки памяти - неправильное использование статики. Статическая переменная хранится в ее классе, а затем в загрузчике классов. Хотя класс можно собирать мусором, это редко происходит в течение жизненного цикла приложения. Часто статика используется для хранения информации кеша или обмена состоянием между потоками. Если этого не делать прилежно, легко получить утечку памяти. По этой причине следует избегать статических изменяемых коллекций любой ценой. Хорошее архитектурное правило - вообще не использовать изменяемые статические объекты и довольствоваться лучшими альтернативами.

IKolomin: Новая страница: «В этом разделе объясняются часто возникающие проблемы с памятью, такие как утечки памят...»

2021-11-30T13:23:57Z

Новая страница: «В этом разделе объясняются часто возникающие проблемы с памятью, такие как утечки памят...»

Новая страница

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

== Утечки памяти ==
Наиболее распространенная проблема утечки памяти - это растущие утечки памяти или постоянный рост утечек объектов. Эти утечки можно легко отследить с помощью дампов трендов или гистограмм.

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

Ниже приведены некоторые из причин утечки памяти:

Thread local variables

* <code>ThreadLocal</code> variables are used to bind a variable or a state to a thread. Each thread has its own instance of the variable. While <code>ThreadLocal</code> variables can be useful, they can also be dangerous. They are used to track a state, such as the current transaction ID, but sometimes hold some more information. A <code>ThreadLocal</code> variable is referenced by its thread and its lifecycle is bound to it. In most application servers, threads are reused via thread pools and are never garbage collected. If the application code does not carefully clear the <code>ThreadLocal</code> variable, it results in a nasty memory leak. Such leaks can be easily discovered with a heap dump by looking at the <code>ThreadLocalMap</code> and following the references. In the above screen, the heapdump indicates that over 4K objects, which amount to around 10MB in size, are held by <code>ThreadLocal</code> variables. The name of the thread reveals the part of the application that is responsible for the leak.

Mutable static fields and collections

* The most common reason for a memory leak is the wrong usage of statics. A static variable is held by its class and, subsequently, by its classloader. While a class can be garbage collected, it will seldom happen during an application's lifetime. Often, statics are used to hold cache information or share state across threads. If this is not done diligently, it is easy to get a memory leak. For this reason, static mutable collections must be avoided at all costs. A good architectural rule is to not use mutable static objects at all and settle for better alternatives.