Інтродукція
Великий проект на Spring. IOC, Autowiring, діла-дрова…
Є группа споріднених бінів, що хитромудро кастомно ініціалізуються. Щоб звести їх ініціалізацію докупи, є ще один бін, який має їх усіх приавтовайреними своїми полями. Після прив'язки своїх полів, цей бін запускає їх ініціалізацію. Все класно, все ініціалізується. З метою покращити перформанс, ініціалізацію споріднених бінів переведено в паралельний режим…
Проблема
В паралельному режимі виникають дедлоки. Тривалий пошук виявив, що проблема стосується не взаємовідносин бінів у «родині», а що лочить їх оцей самий ініцалізуючий бін… Гм, якого?..

Ліричний відступ
«Так, треба щоб цей бін ініціалізував усіх отих, але після того, як вони будуть до нього прив'язані. тобто після встановлення усіх властивостей, чи, як кажуть англійці, afterPropertiesSet(). Туди ми ініціалізіцію і прикрутимо… Так, працює, чудово. А тепер ще асинхронний варіант...»

Ср@^а, або Звідки ноги ростуть
AbstractBeanFactory наслідується від DefaultSingletonBeanRegistry, в котрому у багатьох методах використовується блокування по полю singletonObjects. Зокрема, таке блокування відбувається під час виклику метода getBean(). Штука в тому, що дія метода afterPropertiesSet() потрапляє «всередину» цього блокування, і… і коли у нас один потік, то все нормально, бо блокування належить йому. А коли потоків стає багато, починаються дедлоки (головний потік чекає завершення «відбрунькованих»).

Вирішення
Не пхати кастомну ініціалізацію у afterPropertiesSet(). Зробити окремий метод і викликати його з іншого місця, після того, як контейнер видасть сформований ініціалізуючий бін.