Pull to refresh
23
9.1
Сергей Б. @sergey-b

Пользователь

Send message
Сейчас вот такую. Эксперименты ставил на более ранней версии восьмерки.

java version «1.8.0_102»
Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)
Весь оверхед связан с необходимостью автоматической сборки мусора. Если ваши алгоритмы предполагают наличие 100 млн объектов с возможностью произвольного доступа, то имеет смысл задуматься о самостоятельном управлении памятью, которую они занимают. Все эти объекты должны существовать вместе и уничтожаться будут тоже все разом, поэтому нет необходимости гонять сборщик мусора над ними. Поэтому заведите большой массив с данными и обертку, которая их вынимает по различным запросам.
А в восьмерке разве не G1 по умолчанию?
В 8-й яве System.gc() никаких видимых изменений в куче не производит. По крайней мере в тех экспериментах, которые я сам проводил. Единственный надежный способ выполнить полную сборку мусора — это сделать дамп кучи только с живыми объектами.
Мне кажется, что проще использовать возможности binfmt и запускать jar-ы как обычные исполняемые файлы.
Должен заметить, что SimpleDateFormat непотокобезопасный от слова «совсем».
Да, зависит. А также зависит от соотношения количества операций вставки со всеми остальными операциями. Но вывод о том, что ArrayList или ArrayDeque всегда лучше LinkedList, все равно остается неверным. Именно с этим выводом, сделанным в статье, я не согласен. Нетрудно подобрать такие параметры коллекции и варианты использования, при которых LinkedList будет работать лучше.

Кстати, хорошая идея — реализовать LinkedList на массиве. Надо будет при случае попробовать.
ArrayList, хотя и тратит меньше памяти, чем LinkedList, но требует, чтобы память была выделена одним целым куском, а это более дорогой ресурс.

Если есть необходимость вставки в середину, то надо использовать LinkedList, и то, что эта задача названа экзотической, ничего не меняет.
Так и есть. Java 7.

Тогда вобщем-то понятно из-за чего происходило торможение. GC останавливает поток, работающий в synchronized-методе, а за ним останавливаются и многие другие потоки на входе в этот метод. В результате получается, что каждая малая сборка работает как stop-the-world.
Понятно.

А правильно ли я понимаю, что G1 во время малой сборки приостанавливает отдельные потоки?
Размер кучи был 6 Гб. gc.log в наличии. Подскажите, что в нем посмотреть?

Меня вот такие записи смутили

[Full GC 2171M->671M(6144M), 4.1407616 secs]
[Eden: 290.0M(496.0M)->0.0B(814.0M) Survivors: 40.0M->0.0B Heap: 2171.3M(6144.0M)->671.9M(6144.0M)], [Perm: 524287K->252914K
(253952K)]
[Times: user=5.05 sys=0.42, real=4.13 secs]
Размер кучи 10 Гб. 24 логических ядра на виртуальной машине, если память мне не изменяет.
По пропускной способности. Времена отклика тоже были хуже, и, что самое неприятное, были нестабильны.
Наблюдал работу G1 под нагрузкой. По сравнению с ParallelGC просадка 30-40%. Зависит, конечно, от конкретной системы, но я бы пользоваться G1 без сравнительного тестирования не рекомендовал.
А как у Scala обстоят дела с IDE?
Мордой некоторые разработчики называют клиентский веб-интерфейс. Обычный профессиональный сленг. Соответственно NEW_MORDA — это обновленный веб-интерфейс.
А кто говорил про проверку картинок?

То есть проблема с 0x202E (RLO) в имени файла вас не интересует?


Такие пустяки ловятся легко без антивируса.

но я ей не доверяю

Почему же?



Паниковский не обязан всему верить.
А кто говорил про проверку картинок? Проверяю только exe, dll, bat, cmd и т. п.

ОС налажена, но я ей не доверяю. Береженого бог бережет.
Если вложение получено из ненадежного источника, то лучше проверить.

Information

Rating
719-th
Location
Москва, Москва и Московская обл., Россия
Works in
Registered
Activity