As written, I think the class is thread-safe.
However, the primary reason that it is thread-safe is that the variables factorForOthers
and factorForTermName
are write only. Since there is no code to read them, there is no possibility that a thread can see them in an inconsistent state.
This of course makes this class singularly useless, and leads us to the obvious conclusion that this is not the real code you are worried about.
If factorForOthers
was exposed by a getter (for example), it would still be thread-safe. (A double
is a primitive, and the reference variable is volatile
If factorForTermName
was exposed then there is definitely a risk that the application as a while will not be thread-safe. It depends on whether the exposed map can be updated. If it can be, then there is a significant thread-safety issue. There are two ways to mitigate that:
You could change
setFactorForTermNameMapping
to wrap theHashMap
usingCollections.unModifiableMap()
. If your intent is that the map should be read-only, then this is the best solution.You could use
ConcurrentHashMap
instead ofHashMap
.