Есть ли в худшем случае реализация JVM? - PullRequest
9 голосов
/ 16 февраля 2009

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

Это может привести к ошибкам, которые трудно обнаружить и которые трудно воспроизвести. Поэтому может быть полезно запустить java-приложение на JVM наихудшего случая, который абсолютно не синхронизирует память между потоками, кроме гарантий в модели памяти Java . Существует ли такая реализация JVM в худшем случае?

Ответы [ 5 ]

2 голосов
/ 16 февраля 2009

Вы можете попробовать использовать Terracotta для кластеризации вашей программы. Это невероятно беспощадно при неправильной синхронизации (которая станет очевидной даже при наличии только одного узла в кластере). Это замечательный вопрос: я часто хотел именно эту способность - я удивлен, что в стандартной JRE -XXJMMExtreme

нет переключателя

Terracotta с открытым исходным кодом и бесплатно для основного продукта.

1 голос
/ 16 февраля 2009

Это может помочь: http://javapathfinder.sourceforge.net/

0 голосов
/ 28 февраля 2013

Ошибки синхронизации обычно трудно воспроизвести, потому что они зависят от тонкой синхронизации между различными потоками, поэтому любая реализация, которая на самом деле пытается "просто запустить вашу программу", не всегда может быть "наихудшей из возможных". Вы не можете воспроизвести более одного способа, которым два потока могут чередовать свои инструкции, если вы просто выполните эти инструкции один раз. Тестирование всех таких комбинаций за один проход еще менее возможно. Один из других авторов предложил Java Pathfinder, и это звучит как хорошая идея, но обратите внимание, что это приложение, которое многократно выполняет один и тот же код, так что вы не можете воспринимать это как просто другую реализацию JVM.

Еще один практический совет - попытаться запустить приложение на как можно большем количестве различных виртуальных машин Java. Попробуйте разных поставщиков, разные версии от одного поставщика, разные архитектуры ЦП и так далее. Несколько лет назад у меня был опыт работы с многопоточным приложением, которое было разработано, протестировано и запущено на JVM от Sun на процессорах Xeon, где оно работало очень хорошо. В какой-то момент я попытался запустить его на виртуальной машине Java J9 IBM с архитектурой POWER, и с первой попытки примерно 2/3 тестов не удалось из-за ошибок синхронизации. Таким образом, тестирование в разных средах может быть достаточно хорошим для выявления скрытых проблем синхронизации.

0 голосов
/ 16 февраля 2009

Есть много способов, которые могут вызвать ошибку параллелизма.

  • Загрузите ваше приложение в гораздо большее количество потоков, чем вы обычно ожидаете. Убедитесь, что этого более чем достаточно, чтобы получить 99% + ЦП.
  • Запустите вашу программу с включенным профилировщиком или отключенным JIT. Это изменяет временные характеристики вашего приложения.
  • Тестирование Java 5 и Java 6 (часто это самый простой и лучший способ найти несколько ошибок). Я не нашел ошибку с использованием Java 7, которая не появлялась в 5/6.

Для JVM в худшем случае попробуйте мобильный телефон. (Ваше приложение, вероятно, не будет работать вообще);)

0 голосов
/ 16 февраля 2009

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

...