Динамическая обработка памяти Java против C ++

Question

Я программист C ++, в настоящее время пытаюсь работать на Java.Работая на C ++, я имею привычку отслеживать динамическое распределение памяти и использовать различные методы, такие как RAII, чтобы избежать утечки памяти.Java, как мы знаем, предоставляет сборщик мусора (GC) для устранения утечек памяти. Так что во время программирования на Java нужно просто отпустить все полезные заботы о куче памяти и оставить GC позаботиться об утечках памяти илииспользуйте подход, аналогичный тому, который используется в языках программирования без GC, попробуйте позаботиться о выделенной памяти и просто позвольте GC позаботиться о тех, которые вы можете упустить.Какой должен быть подход?Каковы недостатки либо?

Answer 1

С Java и .net (и я полагаю, что большинство других языков GC), вам не нужно беспокоиться о куче памяти вообще. нужно беспокоиться о нативных ресурсах, таких как дескрипторы файлов, сокеты, графические примитивы, такие как шрифты и тому подобное. Те, как правило, должны быть «утилизированы», что освобождает родные ресурсы. (В любом случае, они часто располагаются на доработке, но немного сомневаться в том, чтобы вернуться к этому. Утилизировать вещи самостоятельно.)

Answer 2

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

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

Однако, если у вас сильный опыт работы в RAII, вы будете разочарованы, узнав, что в Java нет прямого эквивалента.GC - это первоклассный инструмент для работы с памятью, но нет гарантии, когда (или даже если) будут вызываться финализаторы.Это означает, что первоклассная обработка, применяемая к памяти, не , применяемая к любому другому ресурсу, такому как: окна, соединения с базой данных, сокеты, файлы, примитивы синхронизации и т. Д.

Answer 3

Технически вам не нужно беспокоиться об очистке после выделения памяти, так как все объекты правильно подсчитаны, и GC позаботится обо всем. На практике сверхактивный GC отрицательно повлияет на производительность. Так что, хотя в Java нет оператора delete, вы преуспеете в том, чтобы максимально использовать объекты как можно чаще.

Также в Java нет деструкторов, поскольку объекты будут существовать до тех пор, пока GC не доберется до них. Поэтому в Java есть конструкция finally, которую вы должны использовать, чтобы гарантировать, что все ресурсы, не связанные с памятью (файловые сокеты и т. Д.), Будут закрыты, когда вы закончите с ними. Не полагайтесь на метод finalise, чтобы сделать это для вас.

Answer 4

С помощью GC вы должны:

• все же позаботьтесь о том, чтобы правильно высвобождать ресурсы, не связанные с памятью, такие как файловые дескрипторы и соединения с БД.
• убедитесь, что вы не храните ссылки на объекты, которые вам больше не нужны (например, храните их в коллекциях). Потому что, если вы это сделаете, у вас утечка памяти.

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

Answer 5

В Java GC заботится о выделении памяти и освобождении неиспользуемой памяти. Это не означает, что вы можете полностью игнорировать проблему.

Java GC освобождает объекты, на которые нет ссылок из корня. Это означает, что Java все еще может иметь утечки памяти, если вы не будете осторожны, удаляя ссылки из глобальных контекстов, таких как кэши в глобальных HashMaps и т. Д.

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