Java
Comments 29
-6
Эдак мы скоро к старому доброму C вернёмся. *предвкушая*
GC — зло.
-1
Обычно на нагруженном проекте (ну не сайты-визитки же, вы на яве пишите) есть программисты разной квалификации. И если синьорам GС действительно может иногда мешать, то джуниорам и даже мидлам — он просто необходим (кто дебажил код с «потерянным» указателем — поймёт)
+3
Возможно, вы обзовёте меня еретиком, но не пробовали ли запускать под IKVM? Мне интересно, какова разница в эффективности GC.
UFO landed and left these words here
UFO landed and left these words here
0
Возможно ламерский вопрос, но все же:
Первым делом, конечно же стоит выяснить есть ли утечки памяти.

Как ищите?
+3
Обычно анализатором памяти.
Снимпешь heap dump, открываешь и смотришь кто держит объекты, которые по логике вашего приложения уже должны быть собранными. Часто всякие лисенеры держат сильные ссылки на объекты, которые вам больше не нужны.
Можно снять два снепшота с большим интервалом и посмотреть на различия между ними. Только при открывании снепшота, выставите галочку почистить мертвые объекты.
Так же в некоторых анализаторов есть фичи по анализу хипа на подозрения утечек памяти.
+11
Даже если это совсем просто — напишите пожалуйста пост об этом. Я уверен, это многим было бы интересно. Я к примеру, ни разу сам еще этим не занимался и мне было бы очень интересно это попробовать.
0
Вот тут описаны несколько инструментов, может пригодится. А вообще это тема для отдельной полноценной статьи, потому как ловить эти утечки сложнее, чем те же deadlocks.
0
Если я правильно понял вопрос, и Вы спрашиваете, почему я не упомянул данный подход, то, он не поможет при размере кэша в несколько гигабайт, так как все ваши объекты будут лежать в одном и том же Heap, наряду с объектами которые будут требовать сборки, так что GC надо будет запускаться и сканить всю свою память, что обернется большими паузами.
0
Насколько я понял из статьи о Java off-heap cache, там должен использоваться механизм своппинга на жесткий диск, который, я полагаю, отрабатывает в некоторых случаях гораздо медленнее сборщика мусора?
0
Если вам не нужен персистентный кэш и у вас предостаточно оперативной памяти, то никакого своппинга можно не делать.
0
Насколько я знаю, любой своп хипа на диск убивает GC. Размеры -Xmx и прочих параметров всегда должны ставить так, чтобы не допустить спова.
0
Я имею в виду — при своме на жесткий диск off-heap memory, там есть гарантия, что только этот буфер будет сброшен на диск, а не часть java-heap вместе с ним?
+1
Вообще-то не вижу проблемы с использованием Java array в качестве хранилища памяти. Используем массивы массивов для хранения мультигигабайтных данных. Функции адресации пишутся один раз, а затем работают на ура. С точки зрения GC результирующая структура гораздо проще для обработки, чем обычные объекты: ведь сложность определяется не тем, сколько объект места в памяти занимает, а тем, сколько ссылок есть внутри этого объекта.

Кто-нибудь может объяснить, чем этот подход хуже, чем тот же Unsafe-аллокатор?
0
1) Надо же тогда будет самому управлять свободной памятью в в этом массиве.
2) При FullGC на стадии compact GC придеться копировать все эти гигабайты.
+2
>… замедление работы приложения, так как теперь объекты надо будет сериализовать…
Позвольте, но для записи в off heap память ведь тоже нужно сериализовывать. Или я не верно понимаю?
0
«Если ваш java Heap больше нескольких гигов (в зависимости от требований приложения), то никакие настройки GC вам не помогут. Будь-то CMS, JRocket или даже уже сто лет разрабатываемый G1, ничего вас в этом случае не спасет»

Вот тут хотелось бы побольше конкретики и ссылок на исследования и прочее. Считаем, конечно, что у нас x64 сервер и x64 JVM. Что и где будет падать?
0
Ничто нигде падать не будет. Просто паузы GC будут занимать значительное время. Ссылки дать не могу. В качестве пруфа сходите как-ниудь на javaone, там каждый раз с этим соглашаются. Мой личный опыт это так же подтверждает.
+1
Поддерживаю автора. В общем правильно все написано. Мы боремся с кучей порядка 80-90 Гб в данный момент. Пока приходится разбивать на 3 JVM по 30Гб каждый, что неидельно. И Если приходит FullGC то минут на 15-20 JVM встает. Пробуем сейчас g1 и разговариваем с Azul, но они не дешевые совсем. Также рестартуем сервера раз в 2 недели. Пока держимся.
0
Вроде на недавно прошедшем JavaOne прямо сказали, что G1 им довести до ума для больших куч так и не удалось. Работает отлично на маленьких хипах, но не более того, так что сильно не обольщайтесь на его счет.
0
Да мы и не обольщаемся. Потому с азулом и начали разговаривать, но уж больно это геморное дело. Виртуальная машина и их собственный JVM.
Only those users with full accounts are able to leave comments., please.