-----------------------------------------------------------------
Приношу извинения за специфичный тон, просто этот материал написан не для форума. Переписывать — лениво, а не публиковать — жаль материала.
-----------------------------------------------------------------
В последнее время во многих вакансиях на Java Developer появилось требование знания Java Concurrency/Multithreading. В ответ многие разработчики тут же добавили такую строчку себе в резюме. Я как человек, который проводит собеседования, хотел бы развеять некоторые недоразумения относительно этого термина.
Все проекты связанные с многопоточностью я бы разделил на 3 класса: использующие многопоточность, основанные на многопоточности и те, которые и есть сама многопоточность. К первому классу("использующие") я бы отнес проекты, которые предполагают работу в многопоточной среде. Пример: есть класс BlaBlaBlaFactory, в документации необходимо указать, может ли эта фабрика использоваться одновременно несколькими потоками или нет. Если нет, то сделать ее потокобезопасной с помощью ReentrantLock. Ко второму классу ("основанные на") я бы отнес проекты, в которых использование нескольких потоков является одним из ключевых моментов. Пример: многопоточный кодек видео формата H.264. К третьему классу ("являются ей") я бы отнес проекты, в корне что-то меняющие в отношении потоков. Пример: написание runtime-среды для языка Scala (на Java) с реализацией легковесных потоков и своеобразной моделью памяти.
Так вот, дело в том, что разработчик зачастую указывает на свое знание java concurrency имея в виду первый уровень. Компания же может иметь в виду второй (написание высоконагруженного сервера, написание физического/AI ядра 3D-шутера, написание OLAP-системы — во всех случаях с требованием ОДИН запрос пользователя обрабатывать в НЕСКОЛЬКО потоков). Иногда разработчики не знают про существование уровней выше первого. Особенную лепту в это вносят книги вводного или обзорного характера.
Ниже я привожу ряд вопросов с гипотетического собеседования по java concurrency, относящиеся как к первому так и ко второму уровню. Надеюсь кому-то они покажут направление, в котором возможно развиваться.
Как и на всяком собеседовании, не предполагается, что интервьюируемый ответит на все вопросы. Но предполагается, что опрашиваемый по-крайней мере ознакомлен с тематикой. Кроме того определение того 1) что кандидат знает; 2) о чем слышал; 3) о чем не слышал; позволяет составить о нем более полное мнение.
1. Назовите различия между Collections.synchronizedMap(new HashMap()) и ConcurrentHashMap.
2. Что такое кооперативная многозадачность и она ли ли в Java. Если да, то какие преимущества. Если нет, то какая тогда в Java?
3. Что такое "зеленый потоки" и они ли ли в Java (в HotSpot JVM.6)?
4. Различия в интерфейсах Runnable и Callable.
5. Напишите минимальный неблокирующий стек (всего два метода — push() и pop()).
6. Напишите минимальный copy-on-write ArrayList (всего четыре метода — void add(int indx, int item), int get(int indx), void remove(int indx), int size()).
7. Различя между Thread.isInterrupded() и Thread.interrupded().
8. Что происходит при вызове Thread.interrupt()?
9. Некоторые из следующих методов deprecated а некоторые и не были никогда реализованы. Какие? Thread.interrupt(), Thread.stop(), Thread.yield(), Thread.suspend(), Thread.resume(), Thread.join(), Thread.start(), Thread.run(), Thread.sleep().
10. Что Вы знаете о асинхронных вызовов методов? Есть ли это в самом языке Java? Если есть, то как реализовано? Если нет, то как бы Вы реализовали?
11. Перечислите ВСЕ причины по которым может выскочить InterruptedException.
12. Что изменилось между JMM до Java 5 и NewJMM после Java 5?
13. В классе String все поля финальные. Можно ли убрать ключевое слово финал? Ведь сеттеров все равно нет — следовательно поля нельзя переустановить.
14. Что такое ordering, visibility, atomicity, happend-before, mutual exclusion. И показать на примерах volatile, AtomicInteger, synchronize{} — что из вышеперечисленного списка присутствует и при каких вариантах использования.
15. Назовите отличия synchronize{} и ReentrantLock.
16. Что из данных вызовов создает happend-before: Thread.sleep(), Thread.join(), Thread.yield(), Thread.start(), Thread.run(), Thread.isAlive(), Thread.getState()?
17. Перечислите известные Вам способы борьбы с priority inversion, назовите классы систем где они особенно опасны.
18. Перечислите известные Вам способы 1)избежать 2)побороть возникшие deadlock-и (представьте, что вы пишете ядро RDBMS).
19. Расскажите о паттернах Reactor/Proactor?
20. Что такое "monitor"?
21. Что такое "private mutex"?
22. Что такое "priority inheritance"?
23. Что такое "backoff protocol (expotential backoff)"?
24. Что такое "task stealing"?
25. Что такое "ABA problem"?
26. Что такое "test-end-set"?
27. Что такое "test-and-test-end-set"?
28. Что такое "spin lock"?
29. Что такое "sequential consistency"?
30. Что такое "sense-reversing barrier"?
31. Что такое "safe publication"?
32. Что это за свойство — "reentrancy"?
33. Что такое "recursive parallelism"?
34. Что такое "iterative parallelism"?
35. Что это за вариант архитектуры "pipeline"?
36. Что такое "poison message"?
37. Что такое "mutual exclusion"? Примеры как добиться в Java.
38. Что такое "condition waiting"? Примеры как добиться в Java.
39. Преимущества SheduledThreadPool перед java.util.Timer.
40. Различия между java.util.concurrent.Atomic*.compareAndSwap() и java.util.concurrent.Atomic*.weakCompareAndSwap().
41. Что в SynchronousQueue уникально для BlockingQueue.
42. Что такое "рандеву"? При помощи каких классов в Java его можно организовать?
43. Что такое "false sharing". Может ли происходит в Java. Если есть, то приведите примеры и как бороться. Если нет, то как побороли разработчики JVM.
44. Thread.getState() возвращает экземпляр Thread.State. Какие возможны значения?
45. Напишите простейший ограниченный буфер для многих производителей/многих потребителей с использованием synchronize{}. С использованием ReentrantLock.
46. У ReentrantLock созданного с аргументом true все же один из методов захвата блоктровки — не fair. Какой? Как это обойти?
47. Приведите наиболее существенное отличие между CountDownLatch и Barrier.
48. Что Вы знаете о Erlang? Что в нем есть существенного связанного с многопоточностью такого, чего нет в Java?
49. Что Вы знаете о CSP? Что в нем есть существенного связанного с многопоточностью такого, чего нет в Java?
50. Отличие Thread.start() и Thread.run()?
Re: Собеседование по Java Concurrency
От:
Аноним
Дата:
01.12.09 19:42
Оценка:
Очень интересный пост, спасибо !
многое из вопросов знакомо, многое нет.
Вы б не могли(раз уж начали эту тему) пойти до конца и написать короткие ответы на эти вопросы.
Я думаю это было б интересно многим и можно было б пойти дальше и разместить такую статью на RSDN.
Здравствуйте, Golovach Ivan, Вы писали:
GI> Ниже я привожу ряд вопросов с гипотетического собеседования по java concurrency, относящиеся как к первому так и ко второму уровню. Надеюсь кому-то они покажут направление, в котором возможно развиваться.
Интересно, а если я могу ответить (подробно, с примерами) где-то на 40 вопросов — это много?
GI>27. Что такое "test-and-test-end-set"?
"Test And Test-And-Set"?
GI>49. Что Вы знаете о CSP? Что в нем есть существенного связанного с многопоточностью такого, чего нет в Java?
Тут точно CSP или всё-таки CPS?
Кстати, а где классический вопрос про double check singleton?
Здравствуйте, Cyberax, Вы писали:
C>Кстати, а где классический вопрос про double check singleton?
видимо, заключён где-то между 11-м и 13-м вопросами, по крайней мере, собеседующий, видя определённую продвинутость в ответе на 12 вопрос, может эту тему затронуть
2Golovach Ivan:
+1 к Аноним.
Если вас не затруднит напиши ответ по паре предложений, на каждый вопрос.
Или хотя бы на вопросы, которые вы считаете более мудреными, чем остальные
Здравствуйте, Myra, Вы писали:
M>2Golovach Ivan: M>+1 к Аноним. M>Если вас не затруднит напиши ответ по паре предложений, на каждый вопрос. M>Или хотя бы на вопросы, которые вы считаете более мудреными, чем остальные
2Golovach Ivan
Я присоединяюсь к коментам. Спасибо за пост, если не сложно очень хочется получить ответы.
Большое спасибо, открылось огромное поле для размышлений.
У меня просьба как раз не давать ответов на вопросы Ибо не удержусь, прочту, а знания, легко полученные, также легко и уйдут, оставив ложное чувство спокойствия и уверенности в своих силах
--
WBR, Alexander
Re: Собеседование по Java Concurrency
От:
Аноним
Дата:
02.12.09 12:27
Оценка:
Спасибо, теперь я знаю что ничего не знаю
Подскажете, что имеет смысл читать, кроме java concurrency in practice? Понятно, что можно насобирать по кусочкам в инете, но есть ли что-то системное?
Попробую поотвечать (насколько хватит времени): GI>1. Назовите различия между Collections.synchronizedMap(new HashMap()) и ConcurrentHashMap.
В SynchronizedMap просто все операции синхронизированы, что не делает её полностью threadsafe. В частности, нужно явно делать синхронизацию при её обходе с помощью итераторов. Кроме того, блокировка требуется для всех методов — как читающих, так и мутирующих.
В ConcurrentHashMap _обычно_ используется модель many-readers one-writer, кроме того, её можно безопасно итерировать без синхронизации.
GI>2. Что такое кооперативная многозадачность и она ли ли в Java. Если да, то какие преимущества. Если нет, то какая тогда в Java?
Кооперативная многопоточность требует явной передачи управления другому потоку, в отличие от вытесняющей многопоточности, когда выполняющийся поток может быть в любое (ну почти) время быть прерван внешним (по отношению к коду) планировщиком.
В теории, кооперативная многопоточность может быть реализована в какой-нибудь JVM. Для передачи управления можно использовать Thread.yield(). Но я не знаю таких реализаций.
GI>3. Что такое "зеленый потоки" и они ли ли в Java (в HotSpot JVM.6)?
"Зелёные потоки" — это потоки, реализованные внутри самой JVM, а не на уровне ОС. Соответственно, их планированием занимается сама JVM, а не ОС. Это даёт немного более низкий overhead на переключение контекста, но может усложнять реализацию. Кроме того, проблематичной становится комбинация потоков ОС и "зелёных потоков".
В Sun JVM 1.6 их нет, хотя раньше они были реализованы для Solaris'а. Так же, они были в JRockit JVM.
GI>4. Различия в интерфейсах Runnable и Callable.
Метод call() в Callable может бросать исключение (объявлен как throws Exception). Метод run() в Runnable — нет.
GI>5. Напишите минимальный неблокирующий стек (всего два метода — push() и pop()).
Лень
GI>6. Напишите минимальный copy-on-write ArrayList (всего четыре метода — void add(int indx, int item), int get(int indx), void remove(int indx), int size()).
Лень
GI>7. Различя между Thread.isInterrupded() и Thread.interrupded().
Thread.interrupded() — статический метод, вызывающий Thread.isInterrupded() для текущего потока.
GI>8. Что происходит при вызове Thread.interrupt()?
У потока выставляется флаг "interrupted". В случае, если поток блокирован на interruptible-операции, то эта операция будет прервана, а в контекст потока заброшено InterruptedException.
GI>9. Некоторые из следующих методов deprecated а некоторые и не были никогда реализованы. Какие? Thread.interrupt(), Thread.stop(), Thread.yield(), Thread.suspend(), Thread.resume(), Thread.join(), Thread.start(), Thread.run(), Thread.sleep().
Thread.stop(), suspend() и resume() — deprecated, так как они небезопасны.
Thread.destroy() — никогда не был реализован.
Thread.run() — не надо вызывать, так как это выльется в обычный синхронный вызов потоковой функции, а не в запуск нового потока.
GI>10. Что Вы знаете о асинхронных вызовов методов? Есть ли это в самом языке Java? Если есть, то как реализовано? Если нет, то как бы Вы реализовали?
Явного асинхронного вызова методов нет.
GI>50. Отличие Thread.start() и Thread.run()?
Thread.run() — не надо вызывать, так как это выльется в обычный синхронный вызов потоковой функции, а не в запуск нового потока. Стандартная ошибка, нужно использовать thread.start().
Из той же оперы — не надо наследовать свои классы от Thread(), особенно если в них есть метод setName()
Ухх... Могу дальше поотвечать на интересные вопросы.
Здравствуйте, Cyberax, Вы писали:
C>В ConcurrentHashMap _обычно_ используется модель many-readers one-writer, кроме того, её можно безопасно итерировать без синхронизации.
как бы, concurrent hash map можно вообще использовать без синхронизации (если только гранулярность атомарных операций того не требует, что, впрочем, отдельный разговор)
C>В теории, кооперативная многопоточность может быть реализована в какой-нибудь JVM. Для передачи управления можно использовать Thread.yield(). Но я не знаю таких реализаций.
возможно, более полный ответ затронет семантическую разницу между yield и sleep
C>В Sun JVM 1.6 их нет, хотя раньше они были реализованы для Solaris'а. Так же, они были в JRockit JVM.
спасибо, никогда особо не задумывался над этим, поэтому не знал, что их где-то реализовывали
GI>>4. Различия в интерфейсах Runnable и Callable. C>Метод call() в Callable может бросать исключение (объявлен как throws Exception). Метод run() в Runnable — нет.
наверное, можно также коснуться истории, типа Runnable — старый интерфейс, прежде всего, для запуска потоков, а Callable — новый для использования в реализации concurrent-задач
GI>>5. Напишите минимальный неблокирующий стек (всего два метода — push() и pop()). GI>>6. Напишите минимальный copy-on-write ArrayList (всего четыре метода — void add(int indx, int item), int get(int indx), void remove(int indx), int size()). C>Лень
интересно, что эти вопросы подразумевают.
лично я с ходу не напишу, ибо не только лень, а ещё и лень запоминать наизусть лучшие практики из исходников java.util.concurrent.*.
если придётся что-то своё писать — я туда подсмотрю и сделаю, как надо, но запоминать — увольте.
в-общем, какие-то соревновательные вопросы
GI>>10. Что Вы знаете о асинхронных вызовов методов? Есть ли это в самом языке Java? Если есть, то как реализовано? Если нет, то как бы Вы реализовали? C>Явного асинхронного вызова методов нет.
надо бы упомянуть, что есть их поддержка на уровне стандартной библиотеки, Future там, Executors...
Здравствуйте, Cyberax, Вы писали: GI>>4. Различия в интерфейсах Runnable и Callable. C>Метод call() в Callable может бросать исключение (объявлен как throws Exception). Метод run() в Runnable — нет.
Возвращаемый результат — важнее.
GI>>7. Различя между Thread.isInterrupded() и Thread.interrupded(). C>Thread.interrupded() — статический метод, вызывающий Thread.isInterrupded() для текущего потока.
System.out.println(Thread.isInterrupded());
System.out.println(Thread.isInterrupded());
/... vs. .../
System.out.println(aThread.interrupded());
System.out.println(aThread.interrupded());
Будет ли различным результат обоих кусков, если aThread это текущая нить.
GI>>10. Что Вы знаете о асинхронных вызовов методов? Есть ли это в самом языке Java? Если есть, то как реализовано? Если нет, то как бы Вы реализовали? C>Явного асинхронного вызова методов нет.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
GI>>>4. Различия в интерфейсах Runnable и Callable. C>>Метод call() в Callable может бросать исключение (объявлен как throws Exception). Метод run() в Runnable — нет. ANS>Возвращаемый результат — важнее.
Да, забыл.
ANS>
ANS>System.out.println(Thread.isInterrupded());
ANS>System.out.println(Thread.isInterrupded());
ANS>/... vs. .../
ANS>System.out.println(aThread.interrupded());
ANS>System.out.println(aThread.interrupded());
ANS>
ANS>Будет ли различным результат обоих кусков, если aThread это текущая нить.
Будут, так как isInterrupted() без параметров не очищает флаг interrupted, а interupted() — очищает. Повбывав бы.
GI>>>10. Что Вы знаете о асинхронных вызовов методов? Есть ли это в самом языке Java? Если есть, то как реализовано? Если нет, то как бы Вы реализовали? C>>Явного асинхронного вызова методов нет. ANS>Вопрос о Future?
Ага.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Golovach Ivan, Вы писали:
C>Попробую поотвечать (насколько хватит времени): GI>>1. Назовите различия между Collections.synchronizedMap(new HashMap()) и ConcurrentHashMap. C>В SynchronizedMap просто все операции синхронизированы, что не делает её полностью threadsafe. В частности, нужно явно делать синхронизацию при её обходе с помощью итераторов. Кроме того, блокировка требуется для всех методов — как читающих, так и мутирующих.
C>В ConcurrentHashMap _обычно_ используется модель many-readers one-writer, кроме того, её можно безопасно итерировать без синхронизации.
На счет one-writer не совем точно. Одновременных писателей может быть по числу сегментов в мапе. Параметризуется количество этих сегметов через аргумент concurencyLevel в конструкторе. По умолчанию 16.
GI>>7. Различя между Thread.isInterrupded() и Thread.interrupded(). C>Thread.interrupded() — статический метод, вызывающий Thread.isInterrupded() для текущего потока.
Опять же не совсе верно. Вызвается не Thread.isInterrupded() а Thread.isInterrupded(true). Что в общем то совсем другой метод. По сути возврядает текущее состояние интерапта и сбразывает его.
Здравствуйте, C0s, Вы писали:
C>>В ConcurrentHashMap _обычно_ используется модель many-readers one-writer, кроме того, её можно безопасно итерировать без синхронизации. C0s>как бы, concurrent hash map можно вообще использовать без синхронизации (если только гранулярность атомарных операций того не требует, что, впрочем, отдельный разговор)
Ну так и synchronizedMap можно без синхронизации использовать, только её нельзя без синхронизации итерировать.
C>>В теории, кооперативная многопоточность может быть реализована в какой-нибудь JVM. Для передачи управления можно использовать Thread.yield(). Но я не знаю таких реализаций. C0s>возможно, более полный ответ затронет семантическую разницу между yield и sleep
А в чём она? В некоторых ОС yield реализовывается как Sleep(0). Или то, что во время sleep() может прилететь InterruptedException?
C>>Метод call() в Callable может бросать исключение (объявлен как throws Exception). Метод run() в Runnable — нет. C0s>наверное, можно также коснуться истории, типа Runnable — старый интерфейс, прежде всего, для запуска потоков, а Callable — новый для использования в реализации concurrent-задач
Ну да.
GI>>>5. Напишите минимальный неблокирующий стек (всего два метода — push() и pop()). GI>>>6. Напишите минимальный copy-on-write ArrayList (всего четыре метода — void add(int indx, int item), int get(int indx), void remove(int indx), int size()). C>>Лень C0s>интересно, что эти вопросы подразумевают.
Написать простую реализацию. Там строк 50 получится. Для собеседования самое оно.
GI>>>10. Что Вы знаете о асинхронных вызовов методов? Есть ли это в самом языке Java? Если есть, то как реализовано? Если нет, то как бы Вы реализовали? C>>Явного асинхронного вызова методов нет. C0s>надо бы упомянуть, что есть их поддержка на уровне стандартной библиотеки, Future там, Executors...
Да, это уже лень писать было. Ещё можно рассказать про то, как асинхронные методы в других языках сделаны.
Здравствуйте, Nicht, Вы писали:
GI>>>7. Различя между Thread.isInterrupded() и Thread.interrupded(). C>>Thread.interrupded() — статический метод, вызывающий Thread.isInterrupded() для текущего потока. N>Опять же не совсе верно. Вызвается не Thread.isInterrupded() а Thread.isInterrupded(true). Что в общем то совсем другой метод. По сути возврядает текущее состояние интерапта и сбразывает его.
Да, натыкался. За такой дизайн надо поубивать авторов этого интерфейса.
Здравствуйте, Cyberax, Вы писали:
C>>>В теории, кооперативная многопоточность может быть реализована в какой-нибудь JVM. Для передачи управления можно использовать Thread.yield(). Но я не знаю таких реализаций. C0s>>возможно, более полный ответ затронет семантическую разницу между yield и sleep C>А в чём она? В некоторых ОС yield реализовывается как Sleep(0). Или то, что во время sleep() может прилететь InterruptedException?
считается, что yield останавливает нитку и помещает её в конец очереди выполняемых ниток.
с тем лишь замечанием, что эта очередь базируется на приоритетах.
предположим, нитка у нас озадачена чем-то типа
for (i = 0; i < до_хрена_и_больше; ++i) {
// очередной цикл вычислений и никаких прерываний
yield();
}
если я правильно понимаю, в вытесняющей многозадачности, треды с более низким приоритетом, всё-таки получат рано или поздно слоты для выполнения, пусть их будет пропорционально меньше,
а в кооперативной yield тредам с более низкими приоритетами ничего не даст — просто потому, что будет каждый раз оказываться в очереди впереди них.
напротив, в случае sleep(x) вместо yield() планировщик выполнения на x ms вообще должен изымать нитку из очереди, так что в описанной выше ситуации даже в кооперативной многопоточности треды с более низким приоритетом получат шанс.
Здравствуйте, C0s, Вы писали:
C0s>считается, что yield останавливает нитку и помещает её в конец очереди выполняемых ниток. C0s>с тем лишь замечанием, что эта очередь базируется на приоритетах.
Нет, так как это зависит сугубо от планировщика. Типа, yield просто передаёт ему контроль. А дальше планировщик из приоритетов потоков и количества израсходованного ими времени уже решает кого запускать.
Здравствуйте, Cyberax, Вы писали:
C0s>>считается, что yield останавливает нитку и помещает её в конец очереди выполняемых ниток. C0s>>с тем лишь замечанием, что эта очередь базируется на приоритетах. C>Нет, так как это зависит сугубо от планировщика. Типа, yield просто передаёт ему контроль. А дальше планировщик из приоритетов потоков и количества израсходованного ими времени уже решает кого запускать.
полагаю, это не тот вопрос, на который можно дискутировать с применением "да" или "нет".
т.к. мы обсуждаем не работу планировщика, а то, как это видится со стороны java-кода. я всего лишь показал правдоподобную картину, в которой семантическая разница между yield и sleep будет, и ни javadoc, ни java spec ей не противоречат.
а тот факт, что планировщики бывают разными, а с вытесняющей многозадачностью мы вообще не сталкиваемся, на самом деле, к разговору имеет отдалённое отношение, ибо он сугубо теоретический.
Re[4]: Собеседование по Java Concurrency
От:
Аноним
Дата:
03.12.09 08:19
Оценка:
Здравствуйте, Cyberax, Вы писали:
ANS>>
ANS>>System.out.println(Thread.isInterrupded());
ANS>>System.out.println(Thread.isInterrupded());
ANS>>/... vs. .../
ANS>>System.out.println(aThread.interrupded());
ANS>>System.out.println(aThread.interrupded());
ANS>>
ANS>>Будет ли различным результат обоих кусков, если aThread это текущая нить. C>Будут, так как isInterrupted() без параметров не очищает флаг interrupted, а interupted() — очищает. Повбывав бы.
Здравствуйте, Аноним, Вы писали:
А>Спасибо, теперь я знаю что ничего не знаю А>Подскажете, что имеет смысл читать, кроме java concurrency in practice? Понятно, что можно насобирать по кусочкам в инете, но есть ли что-то системное?
Здравствуйте, Cyberax, Вы писали:
GI>>27. Что такое "test-and-test-end-set"? C>"Test And Test-And-Set"?
C>Кстати, а где классический вопрос про double check singleton?
"Test And Test-And-Set" по сути и есть double check idiom.
Здравствуйте, -VladK-, Вы писали:
GI>>>27. Что такое "test-and-test-end-set"? C>>"Test And Test-And-Set"? C>>Кстати, а где классический вопрос про double check singleton? VK>"Test And Test-And-Set" по сути и есть double check idiom.
Весь вопрос в барьерах
Здравствуйте, ivanU, Вы писали:
C>>Из той же оперы — не надо наследовать свои классы от Thread(), особенно если в них есть метод setName() U>А как лучше делать и почему?
Реализовывать интерфейс Runnable и передавать параметром в конструктор Thread.
C>>>Из той же оперы — не надо наследовать свои классы от Thread(), особенно если в них есть метод setName() U>>А как лучше делать и почему? C>Реализовывать интерфейс Runnable и передавать параметром в конструктор Thread.
Извиняюсь за настырность, но чем такой вариант лучше?
До последнего времени использовал наследование от Thread, никаких подводных камней пока не попадалось.
Здравствуйте, ivanU, Вы писали:
C>>Реализовывать интерфейс Runnable и передавать параметром в конструктор Thread. U>Извиняюсь за настырность, но чем такой вариант лучше? U>До последнего времени использовал наследование от Thread, никаких подводных камней пока не попадалось.
Зачем наследоваться от полноценного класса, если ничего не собираешься использовать, кроме самописаного метода run? Меньше сущностей — больше порядка.
И уже было сказано, что ты можешь получить логическую ошибку (было про метод setName), если не проанализируешь поведение класса, от которого наследуешься.
Здравствуйте, ivanU, Вы писали:
C>>>>Из той же оперы — не надо наследовать свои классы от Thread(), особенно если в них есть метод setName() U>>>А как лучше делать и почему? C>>Реализовывать интерфейс Runnable и передавать параметром в конструктор Thread.
U>Извиняюсь за настырность, но чем такой вариант лучше? U>До последнего времени использовал наследование от Thread, никаких подводных камней пока не попадалось.
В теории ООП считается, что включение порождает меньшую связанность, чем наследование; что в свою очередь благоприятно сказывается на сложности системы.
Например, если ты реализовал какую-то задачу как Runnable, то потом ты можешь запустить её в отдельном потоке с помощью Thread, или запустить её в пуле потоков Fork/Join с помощью ForkJoinTask, или передать в какую-либо другую стороннюю или свою библиотеку для асинхронного или даже синхронного выполнения. Если же ты жёстко отнаследовал от Thread, то ничего такого ты сделать не сможешь (по крайней мере без создания объектов Thread).
Ну и плюс, уже упомянутые, нежелательные коллизии имён.
ANS>>System.out.println(Thread.isInterrupded());
ANS>>System.out.println(Thread.isInterrupded());
ANS>>/... vs. .../
ANS>>System.out.println(aThread.interrupded());
ANS>>System.out.println(aThread.interrupded());
ANS>>
ANS>>Будет ли различным результат обоих кусков, если aThread это текущая нить. C>Будут, так как isInterrupted() без параметров не очищает флаг interrupted, а interupted() — очищает. Повбывав бы.
Кстати, вечно путаю эту хрень. Согласен с "Повбывав бы" — всегда надо в документашку лезть.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
C>>>Реализовывать интерфейс Runnable и передавать параметром в конструктор Thread.
U>>Извиняюсь за настырность, но чем такой вариант лучше? U>>До последнего времени использовал наследование от Thread, никаких подводных камней пока не попадалось.
R>В теории ООП считается, что включение порождает меньшую связанность, чем наследование; что в свою очередь благоприятно сказывается на сложности системы. R>Например, если ты реализовал какую-то задачу как Runnable, то потом ты можешь запустить её в отдельном потоке с помощью Thread, или запустить её в пуле потоков Fork/Join с помощью ForkJoinTask, или передать в какую-либо другую стороннюю или свою библиотеку для асинхронного или даже синхронного выполнения. Если же ты жёстко отнаследовал от Thread, то ничего такого ты сделать не сможешь (по крайней мере без создания объектов Thread). R>Ну и плюс, уже упомянутые, нежелательные коллизии имён.
Стало понятнее, благодарю
А что имелось в виду под "по крайней мере без создания объектов Thread" — как без его создания
я могу запустить свою Runnable задачу (без фреймворков, core java)?
Здравствуйте, ivanU, Вы писали:
U>А что имелось в виду под "по крайней мере без создания объектов Thread" — как без его создания U>я могу запустить свою Runnable задачу (без фреймворков, core java)?
U>>А что имелось в виду под "по крайней мере без создания объектов Thread" — как без его создания U>>я могу запустить свою Runnable задачу (без фреймворков, core java)?
C>
C>yourRunnable.run()
C>
сорри, забыл написать в прошлом посту — в отдельном потоке конечно — я правильно
понимаю, что без создания объекта Thread это невозможно (core java)?
Здравствуйте, ivanU, Вы писали:
U>сорри, забыл написать в прошлом посту — в отдельном потоке конечно — я правильно U>понимаю, что без создания объекта Thread это невозможно (core java)?
Да.
Здравствуйте, ivanU, Вы писали:
U>А что имелось в виду под "по крайней мере без создания объектов Thread" — как без его создания U>я могу запустить свою Runnable задачу (без фреймворков, core java)?
Я имел в виду следующую ситуацию. Допустим класс задачи всё-таки отнаследован от Thread, а мы хотим запустить эту задачу как Fork/Join Task.
Решение конечно не очень хорошее, но теоретически можно создать объект нашего класса, и он тоже будет реализовывать Runnable (т.к. Thread реализует Runnable), и потом из него создать Fork/Join Task. Это решение с созданием объектов Thread, без создания же объектов Thread из нашего класса не получится создать Fork/Join Task (это я имел в виду под "по крайней мере без создания объектов Thread").
Я попробую в одном посте ответить на все замечания.
1) "написать короткие ответы на эти вопросы" — тут короткими ответами не отделаешься, выйдет десяток страниц.
2) "Интересно, а если я могу ответить (подробно, с примерами) где-то на 40 вопросов — это много?" — это только потенциальный работодатель может решить
3) "Test And Test-And-Set"? — да, так более корректно
4) "Тут точно CSP или всё-таки CPS?" — да, именно то хоаровское CSP==Communicating Sequential Processes являющееся скорее нотацией, а не реальным языком программирования. Немного провокационный. Знает ли интервьюируемый вообще про существование CSP, что знает, и если более-менее хорошо знает, то может ему в нем что-то особенно запомнилось/понравилось.
5) "Кстати, а где классический вопрос про double check singleton?" — скорее идиоматическим названием является double-checked locking [The "Double-Checked Locking is Broken" Declaration == http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html]. Если бы целью ставил всесторонние тесты — обязательно бы присутствовал, а так не хотелось вставлять уж слишком ожидаемый вопрос.
6) ""Test And Test-And-Set" по сути и есть double check idiom" — тут не могу согласиться. Скажем, у DCL в варианте из ссылки выше присутствует разбор полета конструктора в Java. какие-то параллели есть, но не тождество.
7) "Подскажете, что имеет смысл читать, кроме java concurrency in practice? Понятно, что можно насобирать по кусочкам в инете, но есть ли что-то системное?"
— Doug Lee. Concurrent Programming in Java. Design Principles and Patterns — Addison Wesley — 2nd edition
— The Art of Multiprocessor Programming (Maurice Herlihy, Nir Shavit)
— по алгоритмам: The little book of semaphores = http://www.greenteapress.com/semaphores/
— по структурам данных: "Concurrent Data Structures" = http://www.cs.tau.ac.il/~shanir/concurrent-data-structures.pdf
— по JMM возьмите отсюда — http://kharkovconcurrencygroup.blogspot.com/2009/09/jmm.html
— advanced JMM = очень полное и детальное описание модели памяти Java (Java Memory Model, JMM) с описанием целей, которые ставились при разработке, и компромиссных решений, которые приходилось принимать = http://unladen-swallow.googlecode.com/files/journal.pdf (thanks to Remark)
— это тусовка вообще всех товарищей из Java concurrency community = http://cs.oswego.edu/pipermail/concurrency-interest/
GI>6. Напишите минимальный copy-on-write ArrayList (всего четыре метода — void add(int indx, int item), int get(int indx), void remove(int indx), int size()).
желательно знать что такая реализация есть в JDK = http://java.sun.com/javase/6/docs/api/java/util/concurrent/CopyOnWriteArrayList.html
GI>9. Некоторые из следующих методов deprecated а некоторые и не были никогда реализованы. Какие? Thread.interrupt(), Thread.stop(), Thread.yield(), Thread.suspend(), Thread.resume(), Thread.join(), Thread.start(), Thread.run(), Thread.sleep().
Базовая статья = http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html
GI>10. Что Вы знаете о асинхронных вызовов методов? Есть ли это в самом языке Java? Если есть, то как реализовано? Если нет, то как бы Вы реализовали?
Нет, рассказать как сделать на Future. Возможно интервьюируемый знает язык с реализацией.
GI>13. В классе String все поля финальные. Можно ли убрать ключевое слово финал? Ведь сеттеров все равно нет — следовательно поля нельзя переустановить.
Изменилась семантика ключевого слова final начиная с Java 5. Теперь просто убрать нельзя. Иначе при non safe publishing строка может вести себя как мутирующая (до Java 5 так могла себя вести и с final). = http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#finalWrong. "The original Java Memory Model allowed this behavior; several JVMs have exhibited this behavior. The new Java Memory Model makes this"
GI>16. Что из данных вызовов создает happend-before: Thread.sleep(), Thread.join(), Thread.yield(), Thread.start(), Thread.run(), Thread.isAlive(), Thread.getState()?
H-B: Thread.join(), Thread.start()
GI>21. Что такое "private mutex"? http://c2.com/cgi/wiki?PrivateMutex
GI>38. Что такое "condition waiting"? Примеры как добиться в Java.
Ожидается просто рассказ про wait()/notify()-notifyAll() + j.u.c.lock.Condition
GI>41. Что в SynchronousQueue уникально для BlockingQueue.
То что нет размера.
GI>42. Что такое "рандеву"? При помощи каких классов в Java его можно организовать?
наиболее стандартно:
Передача в одну сторону — SynchronousQueue
Обмен — Exchanger
GI>43. Что такое "false sharing". Может ли происходит в Java. Если есть, то приведите примеры и как бороться. Если нет, то как побороли разработчики JVM.
— может
— из спеки не следует что массивы и поля объекта расположены в непрерывной области памяти(нет адресной арифметики), но обычно так и есть.
— просто интересные мысли
-- зачастую память в потоке выделяется из thread local buffer — и это немного уменьшает ложное разделение. Плюс перемещающий GC (copy-, compact- , etc) может объекты принадлежащие одному потоку расположить рядом (но тут не знаю вышли ли такие разработки за пределы лабораторий).
GI>44. Thread.getState() возвращает экземпляр Thread.State. Какие возможны значения?
Собственно попытка подловить (в том числе) на понимании разницы между Thread.State.WAITING и Thread.State.BLOCKING.
GI>46. У ReentrantLock созданного с аргументом true все же один из методов захвата блоктровки — не fair. Какой? Как это обойти?
.tryLock(), "If you want to honor the fairness setting for this lock, then use tryLock(0, TimeUnit.SECONDS) which is almost equivalent (it also detects interruption)."
GI>47. Приведите наиболее существенное отличие между CountDownLatch и Barrier.
Ожидаемый ответ — CyclicBarrier(извинения за описку) — "многоразовый", а CountDownLatch — "одноразовый".
GI>48. Что Вы знаете о Erlang? Что в нем есть существенного связанного с многопоточностью такого, чего нет в Java?
Ожидаемое начало ответа — легковесные потоки. Но тут зависит насколько соискатель знает Erlang
Здравствуйте, Аноним, Вы писали:
А>Спасибо, теперь я знаю что ничего не знаю А>Подскажете, что имеет смысл читать, кроме java concurrency in practice? Понятно, что можно насобирать по кусочкам в инете, но есть ли что-то системное?
У меня в голове крутится, что книга Java. Concurrency in Practice является как бы следующим изданием, "переработанным и дополненным" к той, что Вы упоминаете. Это действительно так, или книги совершенно разные и читать надо обе?
Долгое время даже и не знал что написать в ответ, хотя мысли разные приходили.
В основном ваши вопросы затрагивают около-фундаментальные темы вперемешку с Java API,
который можно открыть и почитать или посмотреть исходные коды.
Или, к примеру, Java программист не обязан знать Erlang — не понятно откуда появился этот вопрос.
т.е. как бы около-фундаментальные знания выуживаются из реализаций, а не из факта изучения фундаментальных книг.
The Art of Multiprocessor Programming — у меня, кстати, есть эта книга и я её читал, но она не очень интересна —
посмотреть, конечно, можно. На самом деле, судя по вашим вопросам, вы еще очень многих интересных фундаментальных книг не читали.
т.е. не все вопросы мне кажутся бесмысленными, но сократить логически список нужно.
Здравствуйте, insighter, Вы писали:
I>а какого рода у вас в фирме задачи по многопоточности, что такой серьезный список вопросов?
Последний проект что был — высоконагруженный распределенный игровой сервер. Собственно основные "многопоточные абстрактности" появились когда начали делать его модульным. Конкретно:
— игра — это просто jar-ник брошенный в папку (а всего на одном сервере параллельно висит от 40 до 160 типов игр, и у каждого несколько инстансов для каждого игрока);
— "акции"(как в казино — система лотерей) — это просто листенеры на события происходящие в играх(старт, ставка, выигрыш, отмена, проигрыш, и т.д.), получающие ивенты по самописной in-process очереди сообщений.
Предпоследний проект — сомописный транзакционный менеджер. Понадобился, когда увязывали работу с несколькими сайтами через один "суперсайт". Особенность была в том, что в каждый момент времени было огромное количество незавершенных транзакций (как на commit-е так и на rollback-е), иногда транзакцию не удавалось завершить буквально сутками (сайт просто отказывается работать именно с этим аккаунтом) и с тем что не для всех действий возможно было написать rollback-действие (скажем, если на счет сайта перечислили деньги, то отменить перевод нельзя никаким образом, возможно только взять другой услуги на эту же сумму) — из-за этого и других "особенностей" писали сами.
Собственно, многопоточность(в том числе терминология, алгоритмы — не только Java API) — это инструментарий, владея им проекты получаются "красивее", быстрее, лаконичнее и, зачастую, функциональнее. Это как Spring, для разработки серверного приложения на Java, в принципе, никакой контейнер не является НЕОБХОДИМЫМ(ни IoC, ни EJB, ни ???), все можно сделать вручную, изобрести кучу велосипедов. Но заметно проще опираться на разработки других. Так и тут, владея инструментарием автоматически начинаешь им пользоваться.
Собственно, пришел к тому, что работа становится следствием умений, а не наоборот. Т.е. ни "Какая работа заставила выучить многопоточность?", а "За какую работу Вы взялись зная многопоточность(алгоритмы, криптографию, etc)?".
Перед этим работал в паре небольших стартапов, сейчас в свободном плавании, рассматриваю предложения
Здравствуйте, markovskiy, Вы писали:
M>Здравствуйте, Golovach Ivan, Вы писали:
M>Долгое время даже и не знал что написать в ответ, хотя мысли разные приходили. M>В основном ваши вопросы затрагивают около-фундаментальные темы вперемешку с Java API,
Согласен. Но это же собеседование на работу, а не на PhD в Стенфорд.
M>который можно открыть и почитать или посмотреть исходные коды.
Опять же — ищется сотрудник, который уже способен с этим работать, а не в состоянии разобраться. Опять же, если человеку необходимо смотреть множество API — это скорее всего к тому, что будет наличие трудноотловимых ошибок. Что-то вроде — "читаю со словарем".
M>Или, к примеру, Java программист не обязан знать Erlang — не понятно откуда появился этот вопрос.
Собственно не совсем понятно что вообще "должен знать Java программист". Только вот Twitter использует Scala, а Facebook — Erlang. Да и близкое знакомство с концепцией actor-ов не помешает.
M>т.е. как бы около-фундаментальные знания выуживаются из реализаций, а не из факта изучения фундаментальных книг.
Согласен. Я же для этого и говорю про первый-второй-третий уровень знаний. Тут вопросы по первому, немного по второму. Вы же хотели бы видеть третий. Но это — не ко мне, не дорос пока еще
M>The Art of Multiprocessor Programming — у меня, кстати, есть эта книга и я её читал, но она не очень интересна - M>посмотреть, конечно, можно. На самом деле, судя по вашим вопросам, вы еще очень многих интересных фундаментальных книг не читали.
Вы могли бы указать конкретный список книг?
M>т.е. не все вопросы мне кажутся бесмысленными, но сократить логически список нужно.
На собеседовании на работу зачастую большинство вопросов кажется "бессмысленными", есть такая беда.
С удовольствием прочитаю Ваш список дополнительных вопросов.
... > Последний проект что был — высоконагруженный распределенный игровой > сервер. Собственно основные "многопоточные абстрактности" появились > когда начали делать его модульным. Конкретно: > — игра — это просто jar-ник брошенный в папку (а всего на одном сервере > параллельно висит от 40 до 160 типов игр, и у каждого несколько > инстансов для каждого игрока); > — "акции"(как в казино — система лотерей) — это просто листенеры на > события происходящие в играх(старт, ставка, выигрыш, отмена, проигрыш, и > т.д.), получающие ивенты по самописной in-process очереди сообщений. > > Предпоследний проект — сомописный транзакционный менеджер. Понадобился, > когда увязывали работу с несколькими сайтами через один "суперсайт". > Особенность была в том, что в каждый момент времени было огромное > количество незавершенных транзакций (как на commit-е так и на > rollback-е), иногда транзакцию не удавалось завершить буквально сутками > (сайт просто отказывается работать именно с этим аккаунтом) и с тем что > не для всех действий возможно было написать rollback-действие (скажем, > если на счет сайта перечислили деньги, то отменить перевод нельзя > никаким образом, возможно только взять другой услуги на эту же сумму) — > из-за этого и других "особенностей" писали сами. > > Собственно, многопоточность(в том числе терминология, алгоритмы — не > только Java API) — это инструментарий, владея им проекты получаются > "красивее", быстрее, лаконичнее и, зачастую, функциональнее. Это как > Spring, для разработки серверного приложения на Java, в принципе, > никакой контейнер не является НЕОБХОДИМЫМ(ни IoC, ни EJB, ни ???), все > можно сделать вручную, изобрести кучу велосипедов. Но заметно проще > опираться на разработки других. Так и тут, владея инструментарием > автоматически начинаешь им пользоваться. > > Собственно, пришел к тому, что работа становится следствием умений, а не > наоборот. Т.е. ни "Какая работа заставила выучить многопоточность?", а > "За какую работу Вы взялись зная многопоточность(алгоритмы, > криптографию, etc)?". > > Перед этим работал в паре небольших стартапов, сейчас в свободном > плавании, рассматриваю предложения
Судя по представленным проектам компания действительно делала довольно
сложные вещи. Значит у нее есть разработчики высокой квалификации. И тем
не менее, она ищит супер-пупер разработчика. Страннно.
Во-первых это дорого. Я, к примеру, не смог бы пройти такое
собеседование, но меньше 2 тыщь баксов и не стал бы рассматривать. А
тот, кто сможет, думаю и пятью тысячами останется недовольным.
Во-вторых — как компания собирается интегрировать такого разработчика в
комманду? Такие разработчики не смогут воплощать чью-то архитектуру. Они
конечно смогут, если требуемая архитектура совпадает с их видением — но
тогда зачем они вам? А если поставить нового разработчика в комманду
выше своих старых сотрудников — это посеет неприязнь между руководством
компании, старыми сотрудниками и новым разработчиком. Как минимум будет
нарушение коммуникации.
"работа становится следствием умений, а не наоборот" — О ЧЕМ ЭТО
ВООБЩЕ??? Пойдите в любой институт, найдите какого-нибудь аспиранта с
кафедры философии, и попросите объяснить вам, что является следствием, а
что причиной (в этой паре работа-умение).
Вернемся к компании, которая ищет супер-пупер разработчика по
Concurrency. Что же могло заставить компанию, которая справляется с
решением сложных проектов искать супер-разработчика? Его дорого искать,
его дорого содержать, его трудно интегрировать в комманду. Мне кажется,
что проблема в "текучке".
Думаю у компании был разработчик (а может быть несколько). Компания
сделала один или несколько продуктов которые хорошо "выстрелили"
(принесли большую прибль). Но компания не поделилась этой приблью с
разработчиком.
А что, мы и не обещали! Это же мы (компания) рисковали своими деньгами,
несколько лет платили зарплату, медстраховку, отпуски, офис... Мы же
регулярно индексировали зарплату. Ну и что, что теперь мы каждый месяц
зарабатываем по миллиону баксов в месяц. Нет, мы не можем заплатить
разработчикам по миллиону — нам же для этого придется несколько месяцев
оставаться без прибыли. Мы даже по 100 тыщь не можем заплатить — это же
огомные деньги. Да и на каком основании — мы так не договаривались!
В итоге — мотивация ушла, разработчики или ушли, или не могут работать
(из-за отсутствия мотивации). Важная часть успеха — опыт разработчиков —
утрачен...
А компания ищет техническое решение социальной проблемы. Придется
огорчить такую компанию — социальные проблемы решаются социальными методами.
Остается только опуститься на примитивный уровень, и сказать, что старые
разработчики ушли из-за своей жадности.
Здравствуйте, Other Sam, Вы писали:
OS>Судя по представленным проектам компания действительно делала довольно OS>сложные вещи. Значит у нее есть разработчики высокой квалификации. И тем OS>не менее, она ищит супер-пупер разработчика. Страннно.
Это чисто субъективно — но это требования не к супер-пупер разработчику.
Достаточно прочитать около "правильных" 10 книг.
OS>Во-первых это дорого. Я, к примеру, не смог бы пройти такое OS>собеседование, но меньше 2 тыщь баксов и не стал бы рассматривать.
Да, Java senior меньше 2000$, полагаю, нигде не получает.
OS>тот, кто сможет, думаю и пятью тысячами останется недовольным.
Ну я, например, остаюсь доволен суммой меньшей чем 5 тонн. В принципе если
знание многопоточки добавляет +500 к зп — уже неплохо.
+100 за XML, +300 за криптографию, +300 за Oracle — так на сеньерскую зп и набегает
OS>Во-вторых — как компания собирается интегрировать такого разработчика в OS>комманду? Такие разработчики не смогут воплощать чью-то архитектуру. Они OS>конечно смогут, если требуемая архитектура совпадает с их видением — но OS>тогда зачем они вам? А если поставить нового разработчика в комманду OS>выше своих старых сотрудников — это посеет неприязнь между руководством OS>компании, старыми сотрудниками и новым разработчиком. Как минимум будет OS>нарушение коммуникации.
Возможно Ваши выводы справедливы для большой оутсорсной компании, но
в стартапах немного другая атмосфера. Нет такого процесса как "интеграция разработчика".
На собеседовании прямо говорят — вот что мы делаем, такие задачи решаем.
Если интересно — давая работать к нам. И боец идет на решения интересных задач.
Атмосфера обсуждения чье решение лучше присутствует постоянно, если докажешь, что
твое лучше — внедряют его.
OS>"работа становится следствием умений, а не наоборот" — О ЧЕМ ЭТО OS>ВООБЩЕ??? Пойдите в любой институт, найдите какого-нибудь аспиранта с OS>кафедры философии, и попросите объяснить вам, что является следствием, а OS>что причиной (в этой паре работа-умение).
Это верно для навыков, получаемых в результате работы. Тут согласен.
Но Вы же и сами можете за сезон прочитать пяток книг по криптографии
и теперь выбирать работу с ее использованием. Идти по некоторому своему
плану развития.
OS>Вернемся к компании, которая ищет супер-пупер разработчика по OS>Concurrency. Что же могло заставить компанию, которая справляется с OS>решением сложных проектов искать супер-разработчика? Его дорого искать, OS>его дорого содержать, его трудно интегрировать в комманду. Мне кажется, OS>что проблема в "текучке".
... OS>Остается только опуститься на примитивный уровень, и сказать, что старые OS>разработчики ушли из-за своей жадности.
Не единственный вариант. Я обычно сталкивался с тем, что создается команда, скажем
2 сениора, 3 мида, 3 юниора. Работает, все ок, но потом в результате увеличения
количества работы сеньеры начинают захлебываться и требуют от командования
еще, скажем 1 сениора, и пару мидлов. Ну вот этого сениора и подбирают долго и нудно.
Т.е. Вы не рассматриваете вариант роста команды, а только замещения ее членов.
Означает ли это, что все имеющееся в наличии у компании "железо" работает с перегрузкой, а добавить еще "железа" почему-то нет возможности ( ), и вот приходится погружаться на "молекулярный" уровень.
Здравствуйте, mselez, Вы писали:
M>высоконагруженный распределенный
M>Означает ли это, что все имеющееся в наличии у компании "железо" работает с перегрузкой, а добавить еще "железа" почему-то нет возможности ( ), и вот приходится погружаться на "молекулярный" уровень.
кстати, не исключено
мне доводилось поставлять решения клиенту, который потихоньку по мере роста выбрал лимит железа в дата-центре, который был ему удобен экономически и географически. начиная с какого-то момента, стало ясно, что это ещё не пик нагрузки, но разом переместить все данные куда-то ещё было практически невозможно, клиент в силу своих экономических внутренних аргументов решил пойти по пути оптимизации софта...
Здравствуйте, mselez, Вы писали:
M>высоконагруженный распределенный
M>Означает ли это, что все имеющееся в наличии у компании "железо" работает с перегрузкой, а добавить еще "железа" почему-то нет возможности ( ), и вот приходится погружаться на "молекулярный" уровень.
1)
Железо было неплохое, но мы уперлись в архитектурные ограничения. Одно из требований было держать 400tps. Но проблема в том, что запросы от пользователей не независимы. Есть много мест, где без вдумчивого подхода происходит сериализация запросов и никакими 400tps не пахнет — падает до 5-15tps. Конкретный пример — модуль "Акции" содержал акцию "Джек-пот", если кратко, то это отчисления с каждой ставки некоторого процента в джек-пот. Тот пользователь, чье отчисление превысило некоторую(секретную) сумму джек-пота — забирает его("сорвать джек-пот"). Сумма существенная, скажем 50.000$. Хитрость в том, что, допустим, каждый игрок отчисляет по 1$, но мы не можем так просто 50.000-ному запросу дать сорвать джек-пот, так как если откатятся предыдущие транзакции, то наш игрок уже не 50.000ный, а, скажем, 49.990-ый. Т.е. в момент потенциального срыва джек-пота приходится либо сериализировать запросы, либо приостанавливать потенциального победителя и вешать его на ожидание коммитов предидущих запросов, но пока 50.000ный не сорвал джек-пот, не понятно что делать с 50.001, 50.002, 50.003 ... — запросами. Ведь любой из них может сорвать джек-пот в случае роллбека скажем 49.999 запроса (а по условиям мы должны были сообщать об этом в запросе-победителе). Т.е. происходит сразу же нарастание очереди ожидания запросов.
А теперь представьте, что сервер будет сдан "сейчас", а модули акций будут дописываться "потом", в течении всей жизни проекта (ну такие вот условия у этого бизнеса). И многие акции должны иметь возможность использовать "глобальные интегральные" характеристики, типа — кол-во запросов до моего, сумма ставок до моей, абсолютный номер моего запроса. И вот при разработке API игрового сервера для подключаемых акций и вылазили все эти "оптимистические блокировки", "условные ожидания", "copy-on-write" но скорее не в смысле java.util.concurrent.*, а в смысле архитектурных решений.
2)
Продукт писался коробочный, так что тут чем ниже требования к железу, тем желательнее для компании.
Здравствуйте, Golovach Ivan, Вы писали:
GI>Железо было неплохое, но мы уперлись в архитектурные ограничения. Одно из требований было держать 400tps. Но проблема в том, что запросы от пользователей не независимы. Есть много мест, где без вдумчивого подхода происходит сериализация запросов и никакими 400tps не пахнет — падает до 5-15tps. Конкретный пример — модуль "Акции" содержал акцию "Джек-пот", если кратко, то это отчисления с каждой ставки некоторого процента в джек-пот. Тот пользователь, чье отчисление превысило некоторую(секретную) сумму джек-пота — забирает его("сорвать джек-пот"). Сумма существенная, скажем 50.000$. Хитрость в том, что, допустим, каждый игрок отчисляет по 1$, но мы не можем так просто 50.000-ному запросу дать сорвать джек-пот, так как если откатятся предыдущие транзакции, то наш игрок уже не 50.000ный, а, скажем, 49.990-ый. Т.е. в момент потенциального срыва джек-пота приходится либо сериализировать запросы, либо приостанавливать потенциального победителя и вешать его на ожидание коммитов предидущих запросов, но пока 50.000ный не сорвал джек-пот, не понятно что делать с 50.001, 50.002, 50.003 ... — запросами. Ведь любой из них может сорвать джек-пот в случае роллбека скажем 49.999 запроса (а по условиям мы должны были сообщать об этом в запросе-победителе). Т.е. происходит сразу же нарастание очереди ожидания запросов.
Раз уж пошла такая пьянка, а чем вызвана возможность ролбека? Вроде как запрос уже весь пришёл, после его валидации (которая обычно может проводиться полностью независимо), что может вызвать роллбек?
И ещё интересно почему в сериализованном режиме обрабатывалось всего 10 транзакций в секунду? Судя по описанию тут вроде никаких особо тяжёлых рассчётов нет. Ввод-вывод, парсинг запроса, формировнаие ответа — вполне может идти параллельно; а сама обработка вроде не особо тяжёлая...
Здравствуйте, Golovach Ivan, Вы писали:
GI>Это чисто субъективно — но это требования не к супер-пупер разработчику. GI>Достаточно прочитать около "правильных" 10 книг.
Вы про какие-то абстрактные книги говорите или имеете в виду вполне конкретные книги? Если конкретные — приведите пожалуйста список.
Здравствуйте, chand0s, Вы писали:
C>Здравствуйте, Golovach Ivan, Вы писали:
GI>>Это чисто субъективно — но это требования не к супер-пупер разработчику. GI>>Достаточно прочитать около "правильных" 10 книг.
C>Вы про какие-то абстрактные книги говорите или имеете в виду вполне конкретные книги? Если конкретные — приведите пожалуйста список.
Заходите на Amazon.com, выбираете в Search раздел Books, печатаете в строке запроса "Parallel Programming".
На билжайший год книг хватит.
Здравствуйте, chand0s, Вы писали:
C>Здравствуйте, Golovach Ivan, Вы писали:
GI>>Это чисто субъективно — но это требования не к супер-пупер разработчику. GI>>Достаточно прочитать около "правильных" 10 книг.
C>Вы про какие-то абстрактные книги говорите или имеете в виду вполне конкретные книги? Если конкретные — приведите пожалуйста список.
] я уже писал
"- Java Concurrency in Practice
— Doug Lee. Concurrent Programming in Java. Design Principles and Patterns — Addison Wesley — 2nd edition
— The Art of Multiprocessor Programming (Maurice Herlihy, Nir Shavit)
— по алгоритмам: The little book of semaphores = http://www.greenteapress.com/semaphores/
— по структурам данных: "Concurrent Data Structures" = http://www.cs.tau.ac.il/~shanir/concurrent-data-structures.pdf
— по JMM возьмите отсюда — http://kharkovconcurrencygroup.blogspot.com/2009/09/jmm.html
— advanced JMM = очень полное и детальное описание модели памяти Java (Java Memory Model, JMM) с описанием целей, которые ставились при разработке, и компромиссных решений, которые приходилось принимать = http://unladen-swallow.googlecode.com/files/journal.pdf (thanks to Remark)
— это тусовка вообще всех товарищей из Java concurrency community = http://cs.oswego.edu/pipermail/concurrency-
interest/"
В принципе первых трех уже вполне достаточно. Если Вы стартуете "с нуля" в многопоточности явы перед этими книгами возможно стоит просмотреть Java Thread Programming(Sams) или Java Threads(OReilly)
перечисленные книжки все в основном по прогопоточности в java, а вот какие-нибудь фундаментальные имеются?
Изобретут вон в дотнете какие-нибудь новые concurrency паттерны — опять переучивать?
Или все так и будет сводится к тем же семафорам и CAS-ам на аппартном уровне и соотв-но паттерны описанные в java мало чем будут отличаться от реализаций в других языках?
C>>Вы про какие-то абстрактные книги говорите или имеете в виду вполне конкретные книги? Если конкретные — приведите пожалуйста список. GI>тут[http://rsdn.ru/forum/java/3633148.1.aspx
] я уже писал GI>"- Java Concurrency in Practice GI>— Doug Lee. Concurrent Programming in Java. Design Principles and Patterns — Addison Wesley — 2nd edition GI>— The Art of Multiprocessor Programming (Maurice Herlihy, Nir Shavit) GI>— ...
Здравствуйте, swein2, Вы писали:
S>Топик конечно старый, S>но раз уж я на него набрел вчера то не поленился и написал ответы у себя http://swein2.blogspot.com/2011/10/concurrency.html
16 — неправильно. isAlive тоже создает happens-before
Здравствуйте, Безон, Вы писали:
Б>Здравствуйте, swein2, Вы писали:
S>>Топик конечно старый, S>>но раз уж я на него набрел вчера то не поленился и написал ответы у себя http://swein2.blogspot.com/2011/10/concurrency.html Б>16 — неправильно. isAlive тоже создает happens-before
Здравствуйте, Golovach Ivan, Вы писали:
GI>----------------------------------------------------------------- GI>Приношу извинения за специфичный тон, просто этот материал написан не для форума. Переписывать — лениво, а не публиковать — жаль материала. GI>-----------------------------------------------------------------
GI> В последнее время во многих вакансиях на Java Developer появилось требование знания Java Concurrency/Multithreading. В ответ многие разработчики тут же добавили такую строчку себе в резюме. Я как человек, который проводит собеседования, хотел бы развеять некоторые недоразумения относительно этого термина.
по-моему это какой-то бред. Если это опросник то должны быть пункты с ответами а,б,в и по теме. А тут неоднозначные вопросы не по теме. И скорей всего если автор сам попытается публично дать ответы на все пункты то ему быстро объяснят в чём именно и насколько он себя переоценивает.
На этом же сайте есть форум про работу, там ежемесячно подобные полотенца постят.
. Переписывать — лениво, а не публиковать — жаль материала.
), и вот приходится погружаться на "молекулярный" уровень.
