Ошибка утечки памяти

Время на прочтение
11 мин

Количество просмотров 26K

1. Введение

Одним из основных преимуществ Java является автоматизированное управление памятью с помощью встроенного сборщика мусора (или сокращенно GC). GC неявно заботится о выделении и освобождении памяти и, таким образом, способен решать большинство проблем, связанных с ее утечкой.

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

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

Утечки памяти — это настоящая проблема в Java. В этом руководстве мы рассмотрим, каковы потенциальные причины утечек, как распознавать их в рантайме и как справиться с ними в нашем приложении.

2. Что такое утечка памяти

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

Утечка памяти плоха тем, что она блокирует ресурсы памяти и со временем снижает производительность системы. Если с ней не бороться, приложение в конечном итоге исчерпает свои ресурсы и завершится с фатальной ошибкой java.lang.OutOfMemoryError.

Существует два различных типа объектов, которые находятся в Heap-памяти (куче) — со ссылками и без них. Объекты со ссылками — это те, на которые имеются активные ссылки внутри приложения, в то время как на другие нет таких ссылок.

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

Признаки утечки памяти

• Серьезное снижение производительности при длительной непрерывной работе приложения

• Ошибка кучи OutOfMemoryError в приложении

• Спонтанные и странные сбои приложения

• В приложении время от времени заканчиваются объекты подключения

Давайте подробнее рассмотрим несколько таких сценариев и как с ними бороться.

3. Типы утечек памяти в Java

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

3.1. Утечка памяти через статические поля

Первый сценарий, который может привести к потенциальной утечке памяти, — это интенсивное использование статических переменных.

В Java статические поля имеют срок жизни, который обычно соответствует полному жизненному циклу запущенного приложения (за исключением случаев, когда ClassLoader получает право на сборку мусора).

Давайте создадим простую Java-программу, которая заполняет статический список:

public class StaticTest {
    public static List<Double> list = new ArrayList<>();

    public void populateList() {
        for (int i = 0; i < 10000000; i++) {
            list.add(Math.random());
        }
        Log.info("Debug Point 2");
    }

    public static void main(String[] args) {
        Log.info("Debug Point 1");
        new StaticTest().populateList();
        Log.info("Debug Point 3");
    }
}

Теперь, если мы проанализируем кучу во время выполнения этой программы, то увидим, что она увеличилась между точками отладки 1 и 2.

Но когда мы оставляем метод populateList() в точке отладки 3, куча еще не убрана сборщиком, как это видно в ответе VisualVM:

Однако в приведенной выше программе, в строке номер 2, если мы просто отбросим ключевое слово static, то это приведет к резкому изменению использования памяти, как показывает отклик:

Первая часть до точки отладки почти не отличается от того, что мы получили в случае static. Но на этот раз после выхода из метода populateList() вся память списка очищается, поскольку у нас нет на него ссылок.

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

Как предотвратить это?

• Минимизируйте использование статических переменных

• При использовании синглтонов полагайтесь на имплементацию, которая лениво, а не жадно загружает объект.

3.2. Через незакрытые ресурсы

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

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

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

Как предотвратить это?

• Всегда используйте блок finally для закрытия ресурсов

• Код (даже в блоке finally), закрывающий ресурсы, сам не должен содержать исключений.

• При использовании Java 7+ можно использовать блок try-with-resources.

3.3. Неправильная имплементация equals() и hashCode()

При определении новых классов очень распространенной ошибкой является отсутствие надлежащих переопределенных методов для equals() и hashCode().

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

Давайте рассмотрим как пример тривиальный класс Person и используем его в качестве ключа в HashMap

public class Person {
    public String name;
    
    public Person(String name) {
        this.name = name;
    }
}

Теперь мы вставим дубликаты объектов Person в Map, использующую этот ключ.

Помните, что Map не может содержать дубликаты ключей:

@Test
public void givenMap_whenEqualsAndHashCodeNotOverridden_thenMemoryLeak() {
    Map<Person, Integer> map = new HashMap<>();
    for(int i=0; i<100; i++) {
        map.put(new Person("jon"), 1);
    }
    Assert.assertFalse(map.size() == 1);
}

Здесь мы используем Person в качестве ключа. В связи с тем, что Map не допускает дублирования ключей, то мы вставили в качестве ключа дубликаты объектов Person, что не должно увеличивать память.

Но поскольку мы не определили правильный метод equals(), дубликаты объектов накапливаются и увеличивают память, поэтому в памяти мы видим больше одного объекта. Куча в VisualVM в этом случае выглядит следующим образом:

Однако, если бы мы правильно переопределили методы equals() и hashCode(), то в этой Map существовал бы только один объект Person.

Давайте рассмотрим правильную имплементацию equals() и hashCode() для нашего класса Person:

public class Person {
    public String name;
    
    public Person(String name) {
        this.name = name;
    }
    
    @Override
    public boolean equals(Object o) {
        if (o == this) return true;
        if (!(o instanceof Person)) {
            return false;
        }
        Person person = (Person) o;
        return person.name.equals(name);
    }
    
    @Override
    public int hashCode() {
        int result = 17;
        result = 31 * result + name.hashCode();
        return result;
    }
}

В этом случае будут верны следующие утверждения:

@Test
public void givenMap_whenEqualsAndHashCodeNotOverridden_thenMemoryLeak() {
    Map<Person, Integer> map = new HashMap<>();
    for(int i=0; i<2; i++) {
        map.put(new Person("jon"), 1);
    }
    Assert.assertTrue(map.size() == 1);
}

После правильного переопределения equals() и hashCode() куча для той же программы выглядит следующим образом:

Другой пример — использование инструмента ORM, такого как Hibernate, который применяет методы equals() и hashCode() для анализа объектов и сохраняет их в кэше.

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

Как предотвратить это?

• Как правило, на практике,  при определении новых сущностей всегда переопределяйте методы equals() и hashCode().

• Недостаточно их просто переопределить, это необходимо сделать оптимальным образом. Для получения дополнительной информации ознакомьтесь с нашими учебными пособиями Generate equals() and hashCode() with Eclipse и Guide to hashCode() in Java.

3.4. Внутренние классы, которые ссылаются на внешние 

Это происходит в случае нестатических внутренних классов (анонимных классов). Для инициализации они всегда требуют экземпляр внешнего класса.

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

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

Однако, если мы просто объявим внутренний класс как статический, то память уже будет выглядеть так:

Как предотвратить это?

• Если внутреннему классу не нужен доступ к членам внешнего класса, подумайте о том, чтобы превратить его в статический.

3.5. Через методы finalize()

Использование финализаторов — еще один источник потенциальных проблем с утечкой памяти. Когда метод finalize() класса переопределяется, то объекты этого класса не сразу убирают в мусор. Вместо этого GC ставит их в очередь на финализацию, которая происходит позже.

Кроме того, если код метода finalize(), не является оптимальным, а также очередь финализации не успевает за сборщиком мусора Java, то рано или поздно приложение столкнется с ошибкой OutOfMemoryError.

Для демонстрации возьмем класс, в котором мы переопределили метод finalize(), и его выполнение занимает немного времени. Когда большое количество объектов данного класса собирается в мусор, то в VisualVM это выглядит так:

Однако если мы просто удалим переопределенный метод finalize(), то та же программа даст следующий ответ:

Как предотвратить это?

• Мы всегда должны избегать финализаторов

Более подробно о finalize() читайте в разделе 3 (Как избежать использования финализаторов) нашего руководства по методу finalize в Java.

3.6. Интернированные строки

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

Если мы считываем огромный объект-массив String и вызываем для него intern(), то он попадает в пул строк, который находится в PermGen (постоянной памяти) и будет оставаться там до тех пор, пока работает наше приложение. Это блокирует память и создает большую ее утечку в нашем приложении.

PermGen для этого случая в JVM 1.6 выглядит в VisualVM следующим образом :

В отличие от этого, если мы просто читаем строку из файла и не интернируем ее, PermGen выглядит так:

Как предотвратить это?

• Самый простой способ решить эту проблему — обновить Java до последней версии, так как начиная с Java версии 7 пул строк перемещен в HeapSpace.

• При работе с большими строками увеличьте размер пространства PermGen, чтобы избежать возможных ошибок OutOfMemoryErrors:

-XX:MaxPermSize=512m

3.7. Использование ThreadLocals

ThreadLocal (подробно рассматривается в учебнике «Введение в ThreadLocal в Java«) — это конструкция, которая дает нам возможность изолировать состояние для конкретного потока, тем самым позволяя достичь его безопасности.

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

Несмотря на все преимущества, переменные ThreadLocal являются спорными, поскольку они могут приводить к утечкам памяти при неправильном использовании. Joshua Bloch однажды прокомментировал применение локальных переменных потоков:

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

Утечки памяти при использовании ThreadLocals

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

Современные серверы приложений используют пул потоков для обработки запросов вместо создания новых (например, Executor в Apache Tomcat). Более того, они также используют отдельный загрузчик классов.

Поскольку пулы потоков в серверах приложений работают на основе концепции повторного использования, они никогда не утилизируются — их используют повторно для обслуживания другого запроса.

Теперь, если какой-либо класс создает переменную ThreadLocal, но явно не удаляет ее, то копия этого объекта останется в воркере Thread даже после остановки веб-приложения, тем самым препятствуя утилизации объекта.

Как предотвратить это?

• Хорошей практикой является очистка ThreadLocals, когда они больше не используются — ThreadLocals предоставляет метод remove(), который удаляет значение текущего потока для этой переменной.

• Не используйте ThreadLocal.set(null) для очистки значения — он в действительности не очищает, а вместо этого ищет Map, связанную с текущим потоком, и устанавливает пару ключ-значение как текущий поток и null соответственно

• Еще лучше рассматривать ThreadLocal как ресурс, который должен быть закрыт в блоке finally, чтобы быть уверенным в его закрытии во всех случаях, даже при исключении:

try {
    threadLocal.set(System.nanoTime());
    //... further processing
}
finally {
    threadLocal.remove();
}

4. Другие стратегии борьбы с утечками памяти

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

4.1. Включить профилирование

Профилировщики Java — это инструменты, которые отслеживают и диагностируют утечки памяти в приложении. Они анализируют, что происходит внутри нашего приложения — например, как выделяется память.

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

В разделе 3 этого руководства мы использовали Java VisualVM. Пожалуйста, ознакомьтесь с нашим руководством по профилировщикам Java, чтобы узнать о различных типах профилировщиков, таких как Mission Control, JProfiler, YourKit, Java VisualVM и Netbeans Profiler.

4.2. Подробная сборка мусора

При активации подробной сборки мусора мы отслеживаем детальную трассировку GC. Чтобы включить эту функцию, нам нужно добавить следующее в конфигурацию JVM:

-verbose:gc

Добавив этот параметр, мы сможем увидеть подробности того, что происходит внутри GC:

4.3. Использование ссылочных объектов для предотвращения утечек памяти

Для борьбы с утечками памяти можно также воспользоваться ссылочными объектами в Java, которые поставляются с пакетом java.lang.ref. С помощью пакета java.lang.ref вместо прямых ссылок на объекты мы используем специальные ссылки, которые позволяют легко собирать мусор.

Очереди ссылок предназначены для того, чтобы мы знали о действиях, выполняемых сборщиком мусора. Для получения дополнительной информации прочитайте Baeldung-учебник «Мягкие ссылки в Java«, а именно раздел 4.

4.4. Предупреждения об утечке памяти в Eclipse

Для проектов на JDK 1.5 и выше Eclipse выдает предупреждения и ошибки всякий раз, когда сталкивается с очевидными случаями утечки памяти. Поэтому при разработке в Eclipse мы можем регулярно посещать вкладку «Проблемы» и быть более бдительными в отношении предупреждений об утечке памяти (если таковые имеются):

4.5. Бенчмаркинг

Мы можем измерить и проанализировать производительность Java-кода, выполняя эталонные тесты. Таким образом, мы можем сравнить производительность альтернативных подходов к выполнению одной и той же задачи. Это поможет нам выбрать лучший из них и поможет сэкономить память.

Для получения более подробной информации о бенчмаркинге, ознакомьтесь с нашим учебным пособием «Микробенчмаркинг с Java«.

4.6. Обзоры кода

Наконец, у нас всегда есть классический, старый добрый способ — сделать простой обзор кода.

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

5. Заключение

Говоря простым языком, мы можем рассматривать утечку памяти как болезнь, которая снижает производительность нашего приложения, блокируя жизненно важные ресурсы памяти. И, как и все другие болезни, если ее не лечить, со временем она может привести к фатальным сбоям приложения.

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

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

Фрагменты кода, которые использовались для генерации ответов VisualVM, показанных в этом руководстве, доступны на GitHub.

Материал подготовлен в рамках курса «Нагрузочное тестирование». Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем курса — приглашаем на день открытых дверей онлайн. Регистрация здесь.

//Создаём пустой указатель
double *pointer;
 
//Создаём массив и получаем ссылку на него
pointer = new double[15];
 
//Указываем тестовое значение для первой ячейки
pointer[0] = 5;
 
//Выведет адрес ячейки и 5, так как по адресу находится первый элемент массива
cout << "Address: " << pointer << " | Value: " << *pointer << "n";
 
delete [] pointer;
cout << "Deletedn";
 
//Адрес остался прежним, но значение будет 0, так как память была очищена
cout << "Address: " << pointer << " | Value: " << *pointer << "n";

Научитесь: Профессия Разработчик на C++ с нуля
Узнать больше

In computer science, a memory leak is a type of resource leak that occurs when a computer program incorrectly manages memory allocations^[1] in a way that memory which is no longer needed is not released. A memory leak may also happen when an object is stored in memory but cannot be accessed by the running code (i.e. unreachable memory).^[2] A memory leak has symptoms similar to a number of other problems and generally can only be diagnosed by a programmer with access to the program’s source code.

A related concept is the «space leak», which is when a program consumes excessive memory but does eventually release it.^[3]

Because they can exhaust available system memory as an application runs, memory leaks are often the cause of or a contributing factor to software aging.

Consequences[edit]

A memory leak reduces the performance of the computer by reducing the amount of available memory. Eventually, in the worst case, too much of the available memory may become allocated and all or part of the system or device stops working correctly, the application fails, or the system slows down vastly due to thrashing.

Memory leaks may not be serious or even detectable by normal means. In modern operating systems, normal memory used by an application is released when the application terminates. This means that a memory leak in a program that only runs for a short time may not be noticed and is rarely serious.

Much more serious leaks include those:

• where a program runs for a long time and consumes added memory over time, such as background tasks on servers, and especially in embedded systems which may be left running for many years
• where new memory is allocated frequently for one-time tasks, such as when rendering the frames of a computer game or animated video
• where a program can request memory, such as shared memory, that is not released, even when the program terminates
• where memory is very limited, such as in an embedded system or portable device, or where the program requires a very large amount of memory to begin with, leaving little margin for leaks
• where a leak occurs within the operating system or memory manager
• when a system device driver causes a leak
• running on an operating system that does not automatically release memory on program termination.

An example of memory leak[edit]

The following example, written in pseudocode, is intended to show how a memory leak can come about, and its effects, without needing any programming knowledge. The program in this case is part of some very simple software designed to control an elevator. This part of the program is run whenever anyone inside the elevator presses the button for a floor.

When a button is pressed:
  Get some memory, which will be used to remember the floor number
  Put the floor number into the memory
  Are we already on the target floor?
    If so, we have nothing to do: finished
    Otherwise:
      Wait until the lift is idle
      Go to the required floor
      Release the memory we used to remember the floor number

The memory leak would occur if the floor number requested is the same floor that the elevator is on; the condition for releasing the memory would be skipped. Each time this case occurs, more memory is leaked.

Cases like this would not usually have any immediate effects. People do not often press the button for the floor they are already on, and in any case, the elevator might have enough spare memory that this could happen hundreds or thousands of times. However, the elevator will eventually run out of memory. This could take months or years, so it might not be discovered despite thorough testing.

The consequences would be unpleasant; at the very least, the elevator would stop responding to requests to move to another floor (such as when an attempt is made to call the elevator or when someone is inside and presses the floor buttons). If other parts of the program need memory (a part assigned to open and close the door, for example), then no one would be able to enter, and if someone happens to be inside, they will become trapped (assuming the doors cannot be opened manually).

The memory leak lasts until the system is reset. For example: if the elevator’s power were turned off or in a power outage, the program would stop running. When power was turned on again, the program would restart and all the memory would be available again, but the slow process of memory leak would restart together with the program, eventually prejudicing the correct running of the system.

The leak in the above example can be corrected by bringing the ‘release’ operation outside of the conditional:

When a button is pressed:
  Get some memory, which will be used to remember the floor number
  Put the floor number into the memory
  Are we already on the target floor?
    If not:
      Wait until the lift is idle
      Go to the required floor
  Release the memory we used to remember the floor number

Programming issues[edit]

Memory leaks are a common error in programming, especially when using languages that have no built in automatic garbage collection, such as C and C++. Typically, a memory leak occurs because dynamically allocated memory has become unreachable. The prevalence of memory leak bugs has led to the development of a number of debugging tools to detect unreachable memory. BoundsChecker, Deleaker, Memory Validator, IBM Rational Purify, Valgrind, Parasoft Insure++, Dr. Memory and memwatch are some of the more popular memory debuggers for C and C++ programs. «Conservative» garbage collection capabilities can be added to any programming language that lacks it as a built-in feature, and libraries for doing this are available for C and C++ programs. A conservative collector finds and reclaims most, but not all, unreachable memory.

Although the memory manager can recover unreachable memory, it cannot free memory that is still reachable and therefore potentially still useful. Modern memory managers therefore provide techniques for programmers to semantically mark memory with varying levels of usefulness, which correspond to varying levels of reachability. The memory manager does not free an object that is strongly reachable. An object is strongly reachable if it is reachable either directly by a strong reference or indirectly by a chain of strong references. (A strong reference is a reference that, unlike a weak reference, prevents an object from being garbage collected.) To prevent this, the developer is responsible for cleaning up references after use, typically by setting the reference to null once it is no longer needed and, if necessary, by deregistering any event listeners that maintain strong references to the object.

In general, automatic memory management is more robust and convenient for developers, as they do not need to implement freeing routines or worry about the sequence in which cleanup is performed or be concerned about whether or not an object is still referenced. It is easier for a programmer to know when a reference is no longer needed than to know when an object is no longer referenced. However, automatic memory management can impose a performance overhead, and it does not eliminate all of the programming errors that cause memory leaks.

RAII[edit]

Resource acquisition is initialization (RAII) is an approach to the problem commonly taken in C++, D, and Ada. It involves associating scoped objects with the acquired resources, and automatically releasing the resources once the objects are out of scope. Unlike garbage collection, RAII has the advantage of knowing when objects exist and when they do not. Compare the following C and C++ examples:

/* C version */
#include <stdlib.h>

void f(int n)
{
  int* array = calloc(n, sizeof(int));
  do_some_work(array);
  free(array);
}

// C++ version
#include <vector>

void f(int n)
{
  std::vector<int> array (n);
  do_some_work(array);
}

The C version, as implemented in the example, requires explicit deallocation; the array is dynamically allocated (from the heap in most C implementations), and continues to exist until explicitly freed.

The C++ version requires no explicit deallocation; it will always occur automatically as soon as the object array goes out of scope, including if an exception is thrown. This avoids some of the overhead of garbage collection schemes. And because object destructors can free resources other than memory, RAII helps to prevent the leaking of input and output resources accessed through a handle, which mark-and-sweep garbage collection does not handle gracefully. These include open files, open windows, user notifications, objects in a graphics drawing library, thread synchronisation primitives such as critical sections, network connections, and connections to the Windows Registry or another database.

However, using RAII correctly is not always easy and has its own pitfalls. For instance, if one is not careful, it is possible to create dangling pointers (or references) by returning data by reference, only to have that data be deleted when its containing object goes out of scope.

D uses a combination of RAII and garbage collection, employing automatic destruction when it is clear that an object cannot be accessed outside its original scope, and garbage collection otherwise.

Reference counting and cyclic references[edit]

More modern garbage collection schemes are often based on a notion of reachability – if you do not have a usable reference to the memory in question, it can be collected. Other garbage collection schemes can be based on reference counting, where an object is responsible for keeping track of how many references are pointing to it. If the number goes down to zero, the object is expected to release itself and allow its memory to be reclaimed. The flaw with this model is that it does not cope with cyclic references, and this is why nowadays most programmers are prepared to accept the burden of the more costly mark and sweep type of systems.

The following Visual Basic code illustrates the canonical reference-counting memory leak:

Dim A, B
Set A = CreateObject("Some.Thing")
Set B = CreateObject("Some.Thing")
' At this point, the two objects each have one reference,

Set A.member = B
Set B.member = A
' Now they each have two references.

Set A = Nothing   ' You could still get out of it...

Set B = Nothing   ' And now you've got a memory leak!

End

In practice, this trivial example would be spotted straight away and fixed. In most real examples, the cycle of references spans more than two objects, and is more difficult to detect.

A well-known example of this kind of leak came to prominence with the rise of AJAX programming techniques in web browsers in the lapsed listener problem. JavaScript code which associated a DOM element with an event handler, and failed to remove the reference before exiting, would leak memory (AJAX web pages keep a given DOM alive for a lot longer than traditional web pages, so this leak was much more apparent).

Effects[edit]

If a program has a memory leak and its memory usage is steadily increasing, there will not usually be an immediate symptom. Every physical system has a finite amount of memory, and if the memory leak is not contained (for example, by restarting the leaking program) it will eventually cause problems.

Most modern consumer desktop operating systems have both main memory which is physically housed in RAM microchips, and secondary storage such as a hard drive. Memory allocation is dynamic – each process gets as much memory as it requests. Active pages are transferred into main memory for fast access; inactive pages are pushed out to secondary storage to make room, as needed. When a single process starts consuming a large amount of memory, it usually occupies more and more of main memory, pushing other programs out to secondary storage – usually significantly slowing performance of the system. Even if the leaking program is terminated, it may take some time for other programs to swap back into main memory, and for performance to return to normal.

When all the memory on a system is exhausted (whether there is virtual memory or only main memory, such as on an embedded system) any attempt to allocate more memory will fail. This usually causes the program attempting to allocate the memory to terminate itself, or to generate a segmentation fault. Some programs are designed to recover from this situation (possibly by falling back on pre-reserved memory). The first program to experience the out-of-memory may or may not be the program that has the memory leak.

Some multi-tasking operating systems have special mechanisms to deal with an out-of-memory condition, such as killing processes at random (which may affect «innocent» processes), or killing the largest process in memory (which presumably is the one causing the problem). Some operating systems have a per-process memory limit, to prevent any one program from hogging all of the memory on the system. The disadvantage to this arrangement is that the operating system sometimes must be re-configured to allow proper operation of programs that legitimately require large amounts of memory, such as those dealing with graphics, video, or scientific calculations.

If the memory leak is in the kernel, the operating system itself will likely fail. Computers without sophisticated memory management, such as embedded systems, may also completely fail from a persistent memory leak.

Publicly accessible systems such as web servers or routers are prone to denial-of-service attacks if an attacker discovers a sequence of operations which can trigger a leak. Such a sequence is known as an exploit.

A «sawtooth» pattern of memory utilization may be an indicator of a memory leak within an application, particularly if the vertical drops coincide with reboots or restarts of that application. Care should be taken though because garbage collection points could also cause such a pattern and would show a healthy usage of the heap.

Other memory consumers[edit]

Note that constantly increasing memory usage is not necessarily evidence of a memory leak. Some applications will store ever increasing amounts of information in memory (e.g. as a cache). If the cache can grow so large as to cause problems, this may be a programming or design error, but is not a memory leak as the information remains nominally in use. In other cases, programs may require an unreasonably large amount of memory because the programmer has assumed memory is always sufficient for a particular task; for example, a graphics file processor might start by reading the entire contents of an image file and storing it all into memory, something that is not viable where a very large image exceeds available memory.

To put it another way, a memory leak arises from a particular kind of programming error, and without access to the program code, someone seeing symptoms can only guess that there might be a memory leak. It would be better to use terms such as «constantly increasing memory use» where no such inside knowledge exists.

A simple example in C++[edit]

The following C++ program deliberately leaks memory by losing the pointer to the allocated memory.

int main() {
     int* a = new int(5);
     a = nullptr;
    /* The pointer in the 'a' no longer exists, and therefore cannot be freed,
     but the memory is still allocated by the system.
     If the program continues to create such pointers without freeing them, 
     it will consume memory continuously.
     Therefore, a leak would occur. */
}

See also[edit]

• Buffer overflow
• Memory management
• Memory debugger
• Plumbr is a popular memory leak detection tool for applications running on Java Virtual Machine.
• nmon (short for Nigel’s Monitor) is a popular system monitor tool for the AIX and Linux operating systems.

References[edit]

External links[edit]

• Visual Leak Detector Archived 2015-12-15 at the Wayback Machine for Visual Studio, open source
• Valgrind, open source
• Deleaker for Visual Studio, proprietary
• Memory Validator for Visual Studio, Delphi, Fortran, Visual Basic. Proprietary.
• Detecting a Memory Leak (Using MFC Debugging Support)
• Article «Memory Leak Detection in Embedded Systems» by Cal Erickson
• WonderLeak, a high performance Windows heap and handle allocation profiler, proprietary

Утечка памяти – это неправильное размещение ресурса в компьютерной программе из-за неправильного распределения памяти. Это происходит, когда неиспользуемая область ОЗУ остается невыпущенной. Утечку памяти не следует путать с утечкой пространства, которая относится к программе, использующей больше оперативной памяти, чем необходимо. Утечка памяти в системе Windows 10/8/7, как говорят, произошла, когда память просто недоступна, несмотря на то, что она не используется.

Утечки памяти в Windows 10

Прежде чем начать, вы должны знать, что утечка памяти – это проблема программного обеспечения для отладки – например, в Java, JavaScript, C/C ++, Windows и т. Д. Физическая замена ОЗУ или жесткого диска не требуется.

Почему это плохо

Очевидно, что утечка памяти – это плохо, потому что это ошибка, недостаток в системе. Но давайте выясним, как именно это влияет на систему:

1. Поскольку память не освобождается, даже когда она не используется, это приводит к ее истощению.
2. Исчерпание памяти приводит к старению программного обеспечения.
3. Уменьшение доступной памяти приводит к увеличению времени отклика и снижению производительности системы.
4. Неконтролируемая утечка памяти может в конечном итоге привести к сбою приложения.

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

Обнаружение утечки

Чтобы решить проблему, нам нужно сначала ее идентифицировать. Основные шаги по обнаружению утечки памяти:

1. Подтверждение . Определение наличия утечки.
2. Поиск утечки памяти в режиме ядра . Поиск утечки, вызванной компонентом драйвера режима ядра.
3. Поиск утечки памяти в пользовательском режиме . Поиск утечки, вызванной драйвером пользовательского режима или приложением.

Распределение памяти

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

1. Функция HealAlloc для выделения кучи памяти. Эквивалентами времени выполнения C/C ++ являются malloc и новые.
2. Функция VirtualAlloc для прямого выделения из ОС.
3. Kernel32 API для хранения памяти ядра для приложения. Пример, CreateFile, CreateThread.
4. User32 API и Gdi32 API.

Предотвращение утечек памяти

Мы все знаем, что профилактика лучше лечения, поэтому есть несколько способов предотвратить утечку памяти.

Мониторинг привычек

Вы должны следить за ненормальным использованием ОЗУ отдельными программами и приложениями. Вы можете перейти в диспетчер задач Windows, нажав CTRL + SHIFT + ESC и добавить такие столбцы, как дескрипторы, объекты пользователя, объекты GDI и т. Д.

Это поможет вам легко отслеживать использование ресурсов.

Инструменты Microsoft для диагностики утечек памяти

Различные инструменты диагностируют утечки памяти для различных режимов выделения:

1. Верификатор приложения диагностирует утечки кучи.
2. UMDH (компонент средств отладки Windows) диагностирует утечки для отдельных процессов, отслеживая выделение кучи памяти.
3. Trace Capture для тщательного анализа использования оперативной памяти.
4. Xperf также отслеживает шаблоны распределения кучи.
5. CRT Debug Heap не только отслеживает выделение кучи, но также позволяет использовать методы кодирования для минимизации утечек.
6. JavaScript Memory Leak Detector отлаживает утечки памяти в кодах.

Советы по использованию

1. Используйте ядра HANDLE и другие умные указатели для ресурсов Win32 и выделения кучи.
2. Получите классы для автоматического управления ресурсами для выделения ядра из библиотеки ATL. Стандарт C ++ имеет auto_ptr для распределения кучи.
3. Инкапсулируйте указатели COM-интерфейса в «умные указатели» с помощью _com_ptr_t или _bstr_t или _variant_t .
4. Мониторинг кода .NET на предмет ненормального использования памяти.
5. Избегайте множественных путей выхода для функций, чтобы к концу функции освободить выделения из переменных в большинстве блоков.
6. Используйте собственные исключения только после освобождения всех выделений в блоке _finally. Оберните всю кучу и обработайте выделения в интеллектуальные указатели, чтобы использовать исключения C ++.
7. Всегда вызывайте функцию PropVariantClear перед повторной инициализацией или удалением объекта PROPVARIANT.

Устранение утечек памяти в Windows

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

1] Закройте процессы и перезапустите.

Если вы видите, что ненужный процесс занимает слишком много ОЗУ, вы можете завершить процесс в диспетчере задач. Вам нужно будет перезагрузить устройство, чтобы освободившееся пространство было доступно для использования другими процессами. Без перезагрузки проблема утечки памяти не будет решена. Одним из конкретных процессов, которые имеют ошибки для замедления работы ПК, является Runtime Broker. Попробуйте, если отключение, которое само по себе работает.

2] Инструменты диагностики памяти

Чтобы получить доступ к встроенному инструменту диагностики памяти для Windows:

1. Сохраните всю вашу важную работу.
2. Нажмите Win + R , чтобы открыть окно Выполнить .
3. Введите команду mdsched.exe в окне Выполнить .
4. Перезагрузите компьютер.
5. После перезапуска выполните базовое сканирование или выберите параметры Расширенные , например Test mix ’или Количество проходов ’.
6. Нажмите F10 , чтобы начать тестирование.

Это все еще временные исправления.

3] Проверить обновления драйверов

Устаревшие драйверы вызывают утечки памяти. Держите все драйверы обновленными:

1. Нажмите Win + R и откройте окно Выполнить . Введите devmgmt.msc и нажмите Enter. Вы попадете в Диспетчер устройств .
2. Проверьте устаревшие драйверы и обновите их все.
3. Для обновлений, которые вы могли пропустить, проверьте в Центре обновления Windows.

Это было просто.

4] Оптимизация производительности

Настройка Windows на производительность будет управлять всем, включая планирование процессора и использование памяти, чтобы предотвратить утечки памяти. Следуй этим шагам:

1. Нажмите правой кнопкой мыши на Этот компьютер ’и выберите настройки Дополнительно на левой панели.
2. На вкладке “ Дополнительно ” перейдите в раздел “ Эффективность “, а затем “ Настройки “.
3. Установите флажок Настроить для лучшей производительности и нажмите ОК .
4. Перезапустите и проверьте, решена ли проблема.

Если это простое решение не сработало, попробуйте следующее решение.

5] Отключить программы, запускаемые при запуске

Отключение проблемных программ – единственный способ избавиться от проблемы утечки памяти. Зайдите в диспетчер задач и отключите программу, создающую проблемы. Если вы не знаете, какие программы создают проблемы, сделайте следующее:

1. Перейдите в Диспетчер задач .
2. Перейдите в “ Запуск “.
3. Отключите автозапуск программ, которые вам не нужно запускать по умолчанию.

6] Дефрагментация жесткого диска

Хотя Windows 10 делает это для вас автоматически, вам может понадобиться время от времени выполнять дефрагментацию жестких дисков для оптимизации производительности:

1. Перейдите на страницу “ Этот компьютер ” или “ Мой компьютер “.
2. Щелкните правой кнопкой мыши системный жесткий диск (обычно диск C:).
3. Перейдите на вкладку Инструменты и выберите Свойства ‘и выберите Оптимизировать ’.
4. Выберите диск для дефрагментации и выберите « Анализировать ».

Перезагрузите компьютер после новой фрагментации.

7] Файл ClearPage при завершении работы

Сейчас становится все сложнее, но не волнуйтесь. Вот как очищать файл подкачки при каждом выключении:

1. Введите regedit в поле поиска, чтобы запустить редактор реестра.
2. Введите этот путь: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerMemory Management
3. Измените значение ClearPageFileAtShutDown на «1».
4. Сохраните изменения и перезагрузите устройство.

Это должно сделать это.

9] Отключить суперпатч

Этот сервис Windows оптимизирует производительность за счет минимизации времени загрузки. Это позволяет Windows управлять использованием оперативной памяти. Жизнь после отключения Superfetch не удобна, но сделайте это, если нужно. По крайней мере, попробуйте это в одиночку, чтобы изолировать проблему:

1. Найдите services.msc и перейдите в диспетчер служб.
2. Найдите Superfetch и нажмите его правой кнопкой мыши, чтобы перейти в Свойства .
3. Выберите « Стоп ».
4. Также Отключить ’сервис из раскрывающегося меню.
5. Перезагрузите компьютер и проверьте, не улучшилась ли производительность.

Включите Superfetch, если этот не работает.

10] Проверка на наличие вредоносных программ

Используйте стороннее антивирусное программное обеспечение или встроенный в Windows 10 Защитник Windows для сканирования и устранения вредоносных программ.Убедитесь, что антивирус обновлен для поддержки вашей ОС, чтобы он не стал причиной утечки памяти.

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