Apply в любом случае меняет in-memory cache, так что по идее чтения после synchronized должны будут вытащить актуальное значения
Unlike commit(), which writes its preferences out to persistent storage synchronously, apply() commits its changes to the in-memory SharedPreferences immediately but starts an asynchronous commit to disk and you won't be notified of any failures. If another editor on this SharedPreferences does a regular commit() while a apply() is still outstanding, the commit() will block until all async commits are completed as well as the commit itself.
да, я перечитал документации и пишут, что если вызваны два apply из разных потоков, то зафиксирует состояние тот что вызван последним. Мне остается синхронизировать потоки,чтобы все apply и операции чтения выполнялись последовательно и можно считать, что не будет ситуации при которой данные еще не записались и чтение выдало не актуальный результат или же ситуации когда два apply устраивают гонку. Что плохо, то что apply не сообщит об ошибке записи