Случайные замедления Java в Mac OS

Question

Я задал этот вопрос несколько недель назад, но у меня все еще есть проблема, и у меня есть некоторые новые подсказки. Оригинальный вопрос здесь:

Случайные замедления Java в Mac OS

По сути, у меня есть Java-приложение, которое разбивает работу на независимые части и запускает их в отдельных потоках. Потоки не имеют синхронизации или элементов общей памяти. Единственными ресурсами, которыми они делятся, являются файлы данных на жестком диске, причем каждый поток имеет открытый файловый канал.

Большую часть времени он работает очень быстро, но иногда он работает очень медленно без видимой причины. Если я подключу к нему профилировщик процессора, он снова начнет работать быстро. Если я сделаю снимок процессора, он скажет, что большую часть своего времени он проводит в «самостоятельном времени» в функции, которая ничего не делает, кроме проверки нескольких (неразделенных несинхронизированных) логических значений. Я не знаю, как это может быть точным, потому что 1, это не имеет смысла, и 2, добавление профилировщика, кажется, выбивает потоки из любого режима, в котором они находятся, и решает проблему. Кроме того, независимо от того, работает ли он быстро или медленно, он всегда завершает работу и выдает один и тот же вывод, и при этом он никогда не падает в общем использовании ЦП (в данном случае ~ 1500%), подразумевая, что потоки не блокируются.

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

Кто-нибудь знает, что это за проблема? Это может быть операционная система (OS X 10.6.2)? Я не смог продублировать его на машине с Windows, но у меня нет такой с аппаратной конфигурацией.

Answer 1

Возможно, немного поздно ответить, но я мог наблюдать подобные замедления, используя Random in Threads, связанный с изменчивой переменной, используемой в java.util.Random - см. Как назначение переменной может привести к серьезному снижению производительности в то время как порядок выполнения (почти) нетронут? для деталей. Если ответ, который я получил, является правильным (и для меня это звучит довольно разумно), замедление может быть связано с адресами в памяти изменчивых переменных, используемых в Random (посмотрите на ответ пользователя «неопровержимый» на мой вопрос, который объясняет проблему гораздо лучше, чем я здесь).

В случае, если вы создаете Random-экземпляры в методе run ваших потоков, вы можете просто попытаться превратить их в переменные объекта и инициализировать их в конструкторе вашего потока: это, скорее всего, обеспечит изменчивые поля ваших случайных экземпляров окажутся в «разных областях» в ОЗУ, которые не должны синхронизироваться между ядрами процессора.

Answer 2

На самом деле это интересная проблема, мне интересно знать, в чем проблема.

• Во-первых, в своем предыдущем вопросе вы сказали, что делите работу между «несколькими» процессорами. Являются ли они физически множественными, как на нескольких машинах? или многоядерный процессор?

• Во-вторых, я не уверен, имеет ли Snow Leopard какое-либо отношение к этому, но мы знаем, что SL представил несколько новых функций в отношении многопроцессорных машин. Так что может быть какая-то проблема с виртуальной машиной в новой ОС. Попробуйте использовать другую версию Java, я знаю, SL использует Java 6 по умолчанию. Попробуйте использовать Java 5.

• В-третьих, вы пытались сделать пул потоков немного меньше, вы говорите о 100 потоках, работающих одновременно. Попробуйте сделать их 20 или 40, например. Посмотрите, если это имеет значение.

• Наконец, мне было бы интересно посмотреть, как вы реализовали многопоточное решение. Мелкие части кода будут хороши

Answer 3

Откуда ты знаешь, что он работает медленно? Как вы знаете, что он работает быстрее, когда профилировщик процессора активен? Если вы выполняете весь прогон под профилировщиком, работает ли он когда-нибудь медленно? Если вы ограничите количество потоков одним, оно будет работать медленно?