форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Обзор средств для поддержки параллелизма в Java"	+/–
Сообщение от opennews (??) on 14-Май-12, 13:03
В статье (http://programmersnook.blogspot.com/2012/05/java.html) с примерами рассматриваются основные возможности Java в области параллелизма, анализируются проблемы которые поддержка параллелизма призвана решить и приводятся некоторые детали реализации. Большинство из приведенной информации актуально для Java 6 и 7. URL: http://programmersnook.blogspot.com/2012/05/java.html Новость: http://www.opennet.dev/opennews/art.shtml?num=33835
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Обзор средств для поддержки параллелизма в Java"	+1 +/–
Сообщение от Аноним (??) on 14-Май-12, 13:03
Спасибо, оценю качество статьи, вот еще на тему http://www.youtube.com/watch?v=cgXC09uwxIQ
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Обзор средств для поддержки параллелизма в Java"	+/–
Сообщение от ДяДя on 14-Май-12, 15:27
Суть проблемы Java и многопоточность в том, что все объекты передаются по ссылке. В Erlang, например (и во многих остальных функциональных языках), все объекты передаются по значению. Т.о. нет разделяемых областей памяти и проблем нет. P.S. Есть http://code.google.com/p/disruptor/ . На LMAX на одном сервере 1000000 запросов в секунду обрабатывается. Стандартными средствами намного меньше. И всё из-за ОС, т.к. дорого обходится парковка и пробуждение потоков. Ну, а со стороны Java GC может помешать. В Disruptor потоки не wait-ятся и новые объекты не создаются. Очередь сообщений тоже строго фиксированного размера(кольцевой буфер), что не вызывает сборку мусора для данных объектов.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Обзор средств для поддержки параллелизма в Java"	+/–
	Сообщение от evgeny_t (ok) on 14-Май-12, 16:01
	ну да как только все обекты передаются по значению возникает другая проблема, пропускная способность памяти )
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	4. "Обзор средств для поддержки параллелизма в Java"	–2 +/–
	Сообщение от user (??) on 14-Май-12, 16:07
	Rust лишен обоих проблем.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	5. "Обзор средств для поддержки параллелизма в Java"	+/–
	Сообщение от жабабыдлокодер (ok) on 14-Май-12, 16:14
	>  http://code.google.com/p/disruptor/ Очень интересная штука. Буду знать. Спасибо.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	6. "Обзор средств для поддержки параллелизма в Java"	+1 +/–
	Сообщение от iZEN (ok) on 14-Май-12, 18:50
	> Суть проблемы Java и многопоточность в том, что все объекты передаются по ссылке. Протестую! В Java объекты передаются копиями ссылок и ведётся учёт времени жизни этих копий ссылок, а через них — времени жизни объекта, на который они ссылаются.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	7. "Обзор средств для поддержки параллелизма в Java"	–1 +/–
	Сообщение от humanoid on 14-Май-12, 21:40
	ну вообще-то подсчет ссылок дорогая операция, поэтому сборщик работает по другому: 1. имеется набор объектов которые доступны всегда + константные объекты, это все называется Root Set 2. на паузе (stop the world) проверяется на какие объекты ссылаются объекты из этого набора 3. проходим так нужное количество итераций, до тех пор пока не дойдем до объектов которые ни на кого не ссылаются 4. все объекты которые мы не пометили попадают под сборку Так же данный метод избавлен от главного недостатка метода с подсчетом ссылок: кольцевые зависимости (А ссылается на Б, Б ссылается на А) По поводу диструптора: 1. магия не только в кольцевом буфере (смотрим доклад с недавнего JavaDay в питере), обычную очередь можно разогнать до сопоставимых результатов 2. да, парковка дорогая операция, поэтому они жгут циклы процессора, лишь бы не останавливаться 3. дополнительная магия их скорости в том что пауз на сборке у них просто нету, так как используют Azule (далеко не у всех такие деньги будут)
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	9. "Обзор средств для поддержки параллелизма в Java"	+/–
	Сообщение от iZEN (ok) on 14-Май-12, 22:14
	> ну вообще-то подсчет ссылок дорогая операция А я и не говорил про подсчёт. Подсчёт — это частный, далеко не самый эффективный случай УЧЁТА ссылок. Объекты в Java передаются копиями ссылок (copy of reference). Ссылки передаются собственными значениями (reference by-value). (Во загнул! Но так оно и есть на самом деле). :)
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	10. "Обзор средств для поддержки параллелизма в Java"	+/–
	Сообщение от humanoid on 15-Май-12, 11:25
	>> ну вообще-то подсчет ссылок дорогая операция > А я и не говорил про подсчёт. Подсчёт — это частный, далеко > не самый эффективный случай УЧЁТА ссылок. > Объекты в Java передаются копиями ссылок (copy of reference). Ссылки передаются собственными > значениями (reference by-value). (Во загнул! Но так оно и есть на > самом деле). :) ну тогда извиняюсь если я неправильно понял, что подразумевалось под УЧЁТОМ
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	11. "Обзор средств для поддержки параллелизма в Java"	+/–
	Сообщение от ДяДя on 15-Май-12, 11:52
	Кстати, да. Циклы процессора расходуются впустую, поэтому не для всяких сообщений эффект будет одинаковым. Если очень много мелких сообщений, то проще тратить циклы процессора, чем останавливать поток.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	12. "Обзор средств для поддержки параллелизма в Java"	+/–
	Сообщение от ДяДя on 15-Май-12, 11:57
	А в Erlang, если не путаю, потоки легковесные и на потоки ОС напрямую не мапятся. Если на текущем процессоре ресурсы кончаются, то порождается новый поток ОС, который обслуживает несколько легковесных потоков Erlang-а.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	8. "Обзор средств для поддержки параллелизма в Java"	+/–
	Сообщение от humanoid on 14-Май-12, 21:59
	> Суть проблемы Java и многопоточность в том, что все объекты передаются по > ссылке. В Erlang, например (и во многих остальных функциональных языках), все > объекты передаются по значению. Т.о. нет разделяемых областей памяти и проблем > нет. про память уже сказали, плодить каждый раз по объекту при передачи далеко не всегда разумно в том же clojure спокойно реализовали Software-Transactional Memory и передают по ссылке Идем дальше: shared immutable объекты - используем объект в качестве параметра, но изменять его нет возможности, нам из него данные получать, зачем для этого плодить новый объект ? Вопрос ведь не в том: можно или нельзя на java писать многопоточный код, а в уровне знаний необходимый для этого. Можно просто накидать блоков синхронизаций и локов - получишь печальку, сделаешь по умному с отсутвсием разделяемых объектов, а если и разделяемымы то обязательно неизменяемыми - коду не на чем будет бороться за ресурсы и избавляешься от проблем синхронизации, все работает быстро и красиво
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема