Джава:Техники и концепции резьбонарезания

Question

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

Прежде всего

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

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

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

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

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

Использование

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

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

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

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

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

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

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

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

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

Удачи :)

Answer 3

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

Видеть Обзор утилит параллелизма для API на многопоточности. Блокирующая очередь<E> может быть полезно например.

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

Видеть Обратный отсчетЗащелка

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

и ЦиклическийБарьер за интересное поведение.

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

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

Answer 4

  

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

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

  

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

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

  

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

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

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