Java Concurrency: альтернатива многопоточности (работа в среде, не поддерживающей потоки)

Question

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

Тогда я читаю статью здесь

http://cscarioni.blogspot.com/2011/09/alternatives-to-threading-in-java-stm.html

Рекомендуется ли следовать советам этой статьи? Какие еще существуют альтернативы?

Ответ Мартину Джеймсу:

Поставщик сообщает мне, что существует только один поток, в котором существует несколько экземпляров компонента (шаблон Factory для создания экземпляра компонента), и каждый экземпляр независимо управляется из его API.

Значит ли это, что я все еще могу использовать несколько потоков при управлении экземплярами каждого компонента, работающими в одном большом потоке?

Answer 1

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

Другой способ - спроектировать приложение так, чтобы код, который работает с нимопределенный объект всегда выполняется в одном потоке.Это не означает, что код, работающий с другим объектом (даже того же класса), не может запускаться в другом потоке.Таким образом, система является многопоточной, но столкновения данных не создаются.

Answer 2

'Поставщик сообщает мне, что существует только один поток, в котором существует несколько экземпляров компонентной сети (шаблон Factory для создания экземпляра компонента), и каждый экземпляр независимо управляется из своего API.'

Это не совсем ясно на 100%. Я думаю, что это означает:

1) Создание компонентов не является потокобезопасным. Может быть, они все хранятся внутри в не-потокобезопасном контейнере. Предположительно, разрушение компонентов также не является потокобезопасным.

2) После создания компоненты «независимо управляемы» - это говорит о том, что они поточно-ориентированы.

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

Answer 3

Все зависит от того, что ваш код на самом деле делает с компонентами.Например, ArrayList не является поточно-ориентированным, но Vector является поточно-ориентированным.Однако, если вы используете ArrayList внутри потока способом, который безопасен для потока или нейтрален для потока, это не имеет значения.Например, вы можете без каких-либо проблем использовать ArrayLists в контейнере JavaEE для веб-служб, поскольку каждый вызов веб-службы будет происходить в своем собственном потоке, и никто в здравом уме не будет иметь потоки веб-службы, взаимодействующие друг с другом.На самом деле Векторы очень плохи в контейнере JavaEE, если вы можете избежать их использования, поскольку они синхронизируются в большинстве своих методов, что означает, что потоки контейнера будут блокироваться до тех пор, пока не будет выполнена какая-либо операция.

Как сказал AlexRвы можете синхронизировать вещи, но лучший подход - это реально посмотреть на ваш код и выяснить, действительно ли потоки будут обмениваться данными и состоянием или уходить и делать свое дело.