I think the problem here is that the building of the configuration does not need to be locked at all.  If a provider of one of these config objects to merge needs some sort of locking, then it should do it... but the lock which is presently here on the private field is completely pointless.

The way this code uses the state is perfectly acceptable if 2 threads request it and end up with 2 different objects the first time, as one will be thrown away.  Any data used from this state is always treated as a transient object, its not something which could be expected to mutate.  IIUC this is how all of the modello-based xml persistence models are used.

Anyways, the problem I believe is not the assignment of the object here, as this can be duplicated IIUC w/o harm, its more about what the implementations of the dynamic configuration providing components are doing and if they are blissfully unaware they are run under a lock or not, and if the lock is removed if they will start to go crazy or not.  And if they do start to go crazy its because they aren't properly locking around the state which they use to build the configuration and certainly not about the state of the private field here which is what the lock is attempting (badly) to protect.