Java: методы и концепции потоков

Question

При использовании потоков я иногда визуализирую их как переплетение 3 или более взаимосвязей между объектами в пространственном контексте. Это не общий сценарий использования, но для того, что я делаю, это полезный способ подумать об этом.

Существуют ли какие-либо API-интерфейсы, которые вы используете, которые помогают поточить? Использовали ли вы потоки таким образом, чтобы не рассматривать их как процесс?

Answer 1

Существуют ли какие-либо API-интерфейсы, которые вы используете для поддержки потоков?

Вы имеете в виду appart от java.util.concurrent? FunctionalJava получил несколько конструкций, которые помогают в параллельном программировании, как описано в учебнике из нескольких частей, который начинается здесь .

Использовали ли вы потоки таким образом, чтобы не рассматривать их как процесс?

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

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

Агенты / Актеры - это обычный способ сделать это. Актер подобен потоку, который имеет кусок состояния, и затем вы можете отправить ему некоторый код и сказать «сделайте это в ваше состояние, когда у вас будет время» или что-то в этом духе.

Answer 2

Прежде всего

Обычный отказ от ответственности: параллельное программирование на любом языке с использованием любого уровня абстракции является сложным и сложным и сопряжено со многими рисками. Примите во внимание:

• Параллельное программирование усложняет любое приложение по величине
• Юнит-тестирование критических секций сложно, а иногда и невозможно
• Воспроизведение ошибок, возникающих в параллельном коде, очень сложно и сильно зависит от архитектуры, версии ОС, версии и т. Д. *

Параллельные API Java

Java прошла долгий путь, чтобы сделать параллельное программирование как можно более простым для разработчиков. В большинстве случаев вы увидите, что java.util.concurrent содержит большинство необходимых вам абстракций:

• Runnable интерфейс и Thread объект, который вы можете расширить. Просто добавьте свой код, и у вас есть готовый поток для запуска
• Хороший набор Executors: постоянный пул, динамический пул, запланированный или любой другой. Просто бросьте Runnable в него, и он сделает все остальное.
• Semaphore s и блокировки всех видов избавят вас от необходимости применять общие методы блокировки.
• Встроенный wait() и notify() API для всех объектов.

Использует

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

• Deadlock - ситуация, когда два или более потоков ожидают неупорядоченных ресурсов, создавая бесконечный цикл ожидания.
• Livelock - два или более потоков, которые вежливо пытаются уступить другому на общем ресурсе, но в итоге не берут его (представьте, что два человека в коридоре подходят друг к другу и постоянно движутся вместе) из стороны в сторону)
• Голодание - один поток занимает большую часть или весь общий ресурс, что лишает другие потоки доступа к нему.

Основная точка (или, когда использовать)

Используйте потоки только тогда, когда параллелизм непосредственно улучшит поведение ваших приложений.

Если вы ожидаете ресурсов ввода-вывода / сети / оборудования, DO создает поток для него, чтобы вы могли продолжать выполнять другие действия.

Если вы просто пытаетесь элегантно разделить вычисления, связанные с ЦП, НЕ используйте потоки. Вы можете просто ухудшить свою производительность.

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

Полезные (онлайн) ресурсы

Самый быстрый способ разобраться в этом состоит в изучении Sun параллелизма . Кроме этого, получите хорошую книгу.

Удачи:)

Answer 3

Параллелизм - это глубокая и сложная тема для обсуждения. Такие книги, как Java Concurrency на практике могут помочь.

См. Обзор утилит параллелизма для API по многопоточности. BlockingQueue может быть полезно, например.

Очередь, которая дополнительно поддерживает операции, ожидающие очереди в стать непустым при получении элемент, и ждать, пока место станет доступно в очереди при хранении элемент.

См. CountDownLatch

Средство синхронизации, позволяющее или более потоков, чтобы ждать, пока набор операции, выполняемые в других темы завершаются.

и CyclicBarrier для интересного поведения.

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

Редактировать : Я сейчас читаю Java Concurrency на практике. Это очень хорошо.

Answer 4

При использовании потоков я иногда визуализирую их как переплетение 3 или более пространственных взаимосвязей между объектами в пространственном контексте.

Звучит сложно, как бы вы, например, поняли 600 потоков? Почему бы не думать о них как о нескольких потоках выполнения, выполняющихся, по-видимому, одновременно.

Существуют ли какие-либо API-интерфейсы, которые вы используете, чтобы помочь многопоточности?

Я полагаю, что самыми простыми и прямыми являются первые совпадения, которые вы найдете. http://www.google.co.uk/search?q=java+threads

Использовали ли вы потоки таким образом, чтобы не рассматривать их как процесс?

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

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