Интересует чуть более подробное описание переменных у класса AuthHolder.
В кейсе у класса AuthHolder используются 3 volatile переменные.
a) CountDownLatch
b) Token
c) PinCode
Не совсем понятно, почему latch объявлен как volatile переменная. Я предполагал, что в его имплементации есть необходимые модели синхронизации.
Также непонятно, почему token объявлен как volatile, ведь getToken()/updateToken вызываем только из synchronized блока authenticate у MainAuthenticator.
countDownLatch мы переприсваиваем в методе refresh(). Так как это обычная ссылка, и дергается она из разных потоков, то теоретически есть вероятность, что потоки будут видеть разные экземпляры ссылки. Внутри то CountDownLatch да, все учтено.
Token и PinCode. Метод getToken() дергается в трех местах, и только одно их них в блоке synchronized. По крайней мере в ветке sample_2 так.
А вообще по опыту старайтесь проектировать ваши классы таким образом, чтобы их потокобезопасность не зависела от других классов и мест вызова методов нашего класса. Сегодня я вызываю с synchronized метода, завтра уже нет. А человек, который убрал, допустим, тот же synchronized и знать не знает, что могут возникнуть тогда коллизии в другом классе.
Отсюда вывод. Либо делайте ваш класс изначально потокобезопасным (volatile - это вполне приемлимо и довольно дешево в плане перфоманса), либо делайте яркие и кричащие комментарии о том, как правильно использовать методы класса. Я выбрал первый вариант.
Интересует чуть более подробное описание переменных у класса AuthHolder. В кейсе у класса AuthHolder используются 3 volatile переменные. a) CountDownLatch b) Token c) PinCode
Не совсем понятно, почему latch объявлен как volatile переменная. Я предполагал, что в его имплементации есть необходимые модели синхронизации. Также непонятно, почему token объявлен как volatile, ведь getToken()/updateToken вызываем только из synchronized блока authenticate у MainAuthenticator.