@VoiceOfUnreason I suppose he simply means : writers acquire a fair lock in the order in which they requested it.

Look into guava's ImmutableMap and matching builder, you'll love how elegant that initializes a Map. The enum is just less handy to use : linear search time and manually building the available classes. With a HashMap it's O(1) search for a key, and you get the available Classes through getKeys().

Then it indeed does mean opening the file again for each line.

Can we see the code of FileUtils.writeStringToFile()? From the looks of it, that will need to open the file again and again. Without profiling though, it's just a guess whether that is your current bottleneck.

Using ConcurrentHashMap would be an even simpler and better solution as its concurrency performance is much better under contention. I'm not sure why you need to have the order of addition to the user record, but if that can be replaced by some kind of sorting by the client code, then switching to ConcurrentHashMap is definitely the way to go.

@ChrisHayes you can also simply roll your own wrapper around an int with an increment() method. The 'elegance' from my solution does not come from using AtomicInteger per se, but from using a mutable value type in the map. If you do use AtomicInteger, you can annotate the class with the JCIP annotation @NotThreadSafe to avoid confusion.

I've added sample code for FlowTypeEnum.

@codesparkle the generic interface should be Comparable<? super T> as a superclass of T may be the one implementing Comparable.