Меня немного смущает, что мапка общая  и хранит разные объекты.
Ещё потоки стартуют через Thread.start 🙂

> Ещё потоки стартуют через Thread.start 🙂
Я спешил)

> Меня немного смущает, что мапка общая  и хранит разные объекты.
Всмысле? Мапка — интежер от Key'я, что значит "хранит разные обьекты"?

Ну у неё в value либо A, либо B, а ключ общий. Если вызвать

A a1 = new A(cache, 42);
A a2 = new A(cache, 123123);
B b = new B(cache, a1, a2);

Т
То у результатов a2 и b будет один ключ. Они друг друга перетрут

A a1 = new A(cache, 42);
A a2 = new A(cache, 123123);
B b = new B(cache, a1, a2);

Это условности гиста, которыми сейчас можно пренебречь

ОК

> Может можно было решить проще? Я что-то упускаю?

чтобы ответить на этот вопрос - надо бы задачу нормально сформулировать, а тут 2 решения - так себе и неработающее)

прошлый опыт создания хитрожопых графов а-ля "давайте в памяти изобразим поток вычисления" говорит, что
1) вложения и рекурсия - опасны для таких задач
2) syncronized - будет тормозить на кейсах от сотенки итемов (на 2 не будет, на 10 не факт)
3) хочешь счастья - сформулируй задачу без безопасной защищенной многопоточной коллекции в середине всего алгоритма
4) полезные слова - лок и volitile. Лок полезен раз в 20 чаще, чего его используют, но при неправильном использовании он отстреливает ногу по колено. volitile наоборот весьма безопасен, но не всегда через него удобно (особенно на коллекциях)

Ещё смущает синхронизация на лямбде. В первом случае, насколько я понимаю, лямбда будет закеширована для всех экземпляров класса A, это значит, что вычисления A1 и A2 не смогут проходить одновременно. Но насчёт кеширования стоит перепроверить мои слова

кстати, готовый алгоритм решения подобных задач - акторы
https://akka.io

в их терминах это даже не задача, а проходной вызов

> это значит, что вычисления A1 и A2 не смогут проходить одновременно

Я думаю —- это не так. Лямбда ведь замкнута на аттрибут? Но при этом фиксирована для инстанса класса. Разве каждый инстанс А не будет иметь свой уникальный инстанс лямбды?

Кстати, на CHM.computeIfAbsent должно работать. javadoc говорит:

The supplied function is invoked exactly once per invocation of this method if the key is absent, else not at all

Короче, вот это нужно уточнить. Не очень понимаю, как в этом случае она будет создана

> 2) syncronized - будет тормозить на кейсах от сотенки итемов (на 2 не будет, на 10 не факт)
Поподробнее этот пункт можно? Сотенки чего конкретно? Инстансов А?

> 3) хочешь счастья - сформулируй задачу без безопасной защищенной многопоточной коллекции в середине всего алгоритма
Если не в многопоточную коллекцию, то куда мемоизировать?

> Поподробнее этот пункт можно? Сотенки чего конкретно? Инстансов А?

итемов в коллекции. Сейчас в примере 2 A и 1 B, если A будет 20, а B - 10 то проблемы будут более очевидными

> Если не в многопоточную коллекцию, то куда мемоизировать?

это вопрос формулировки задачи и ограничений. Конкретно представлнную я бы решал вообще без коллекций, голым кодом и переменными в инстансах, на цепочке стримов (нельзя зафакапить переменную несуществующего инстанса, в отличие от несуществующего ключа коллекции)

пачка не связанных в коллекцию инстансов для вычислений может даже лучше работать. Скалисты не дадут соврать

Я б понял, если б там стоял синхронайз на кеш. Но там синхронайз на лямбду, с расчетом на то что каждый A и B будет иметь уникальный инстанс. Разве они все упрутся в этот синхронайз?

> Разве они все упрутся в этот синхронайз?

скорее всего нет, но в саппорте этого кода не факт что все останется хорошо. Синхронайзд без причины - запашок

если не сказать антипаттерн

Не, я не играю в эту игру с антипаттернами. Я хочу понять — в данном конкретном случае что может пойти не так. Конкретно

ну если такой интерес, а не решить задачу- то, возможно, есть другие желающие ответить)