Этой статьёй я не собираюсь "разрушать легенды" (опровергать что-либо целиком и полностью), а лишь опишу то, что я видел своими глазами и щупал своими руками за свою недолгую карьеру.
Многих начинающих разработчиков беспокоит вопрос о том, справятся ли они с "боевыми" задачами - теми, которые перед ними поставит их первое рабочее место. На различных ресурсах, где общаются начинающие разработчики можно прочитать вопросы типа:
- работать намного сложнее, чем учиться?
- будет ли у меня время освоиться с проектом?
- что, если я буду "тупить" вместо того, чтобы щёлкать задачи как орешки?
Иногда попадаются вопросы по конкретным технологиям и фрэймворкам. Одним из таких вопросов был следующий:
Хочется верить, что проекты, на которых я работал, были достаточно большими для того, чтобы я мог ответить на этот вопрос. В любом случае, буду писать только о том, с чем имел дело.
Самописной многопоточности (многопоточного кода, написанного исключительно с использованием java core и java concurrency) в тех проектах, которые я видел, практически не было. Если где-то она и была, то от неё спешили избавиться. На всех виденных мной проектах "боялись" многопоточности, считали её чем-то вроде стабильного источника heizenbugs.
В основном, на проектах использовались исключительно многопоточные средства, встроенные в фрэймворки (например, в Spring), которые работали под капотом и не требовали вмешательства разработчика.
Отсюда, возможно, проистекает любовь собеседующих к вопросам о многопоточности на технических интервью:
- т.к. на практике с ней никто почти не работает, то и знания о ней у всех довольно скудные, стандартные;
- людям интересно поговорить об этом диковинном зверьке, с которым мало кому из них приходилось встречаться в диких условиях.
Большая удача попасть на собеседование к специалисту, который имеет опыт написания сложного многопоточного приложения и готов рассказать о возможностях применения многопоточности такое, о чём не пишут в учебниках. Можно прочитать не одну книгу по многопоточности, пересмотреть все доклады с конференций на эту тему, но всё это не заменит той информации, которую можно получить от такого разговора. После такого собеседования чувствуешь себя за пару часов прошедшим аспирантуру по многопоточности.
Из своего опыта могу сделать вывод о том, что серьёзно с многопоточностью работают в таких компаниях, которые пишут свой продукт по обработке больших данных с низкой задержкой ответа от сервера, не сильно полагаясь при этом на сторонние наработки. Такие компании можно пересчитать по пальцам. Все остальные, как я уже писал выше, используют для работы с многопоточностью что-то уже созданное кем-то другим и не требующее особого вмешательства разработчика.
Для начинающих разработчиков это одновременно и хорошо и плохо. Хорошо - потому что можно, не имея серьёзного опыта работы с многопоточностью, найти хорошую работу. Плохо - потому что через какое-то время, когда захочется-таки погрузиться в эту область тьмы, найти работу с задачами посерьёзнее, остро почувствуется дефицит необходимых знаний.
Самую сложную задачу по многопоточности я попытался реализовать в одном из двух тестовых заданий, которые писал за всю карьеру. Напрямую от меня не требовали применять многопоточность. Просто, захотелось самому сделать всё красиво в стиле highload, low latency и супер-пупер-multithreading. Я был молод и вдохновлён разговором с интервьюером. ))
Но т.к. я начал реализацию задачи не с того конца, то забуксовал (не хватило времени доделать) и не смог сдать задачу в завершённом виде.
