Знаю, знаю... Прочитав заголовок, хочется голосом волка из мультфильма «Жил был пёс» сказать — «Шо, опять?». Ведь битва этих подходов давно закончилась и разработчики Spring уже поставили точку.

Но недавняя публикация в одном довольно крупном Telegram‑канале заставила меня вернуться к этому вопросу. В качестве главных аргументов против field injection там приводились лишь сложность изоляции в тестах и неудобство создания экземпляров для unit‑тестов.

И хотя с этими пунктами не поспоришь, у многих разработчиков и не только начинающих, остаются вопросы: каковы реальные последствия для самого объекта? Можно ли считать его полноценным сразу после создания new? И почему все современные рекомендации так настаивают на конструкторах?

Поиск ответов показал мне, что аргумент о тестах лишь верхушка айсберга. В глубине, куда я Вас сегодня приглашаю заглянуть, скрываются куда более фундаментальные вопросы принципов объектно‑ориентированного дизайна, гарантий Java Memory Model и уважения к жизненному циклу объекта.

Когда вы пишете synchronized(obj), под капотом происходит целая цепочка событий, которую можно отследить до Mark Word — восьмибайтового служебного поля в каждом Java-объекте. В современных реализациях JVM (таких как HotSpot, OpenJ9, GraalVM) используется динамическая, адаптивная система, которая выбирает наиболее эффективную стратегию блокировки в зависимости от реального поведения потоков.