Volatile is not sufficient here. You need to lock the collection if you want to modify and iterate it concurrently.
That isn't necessarily a problem. Try it, use a profiler to look out for blocked threads.
For organizing it differently, one would need more information about the background.
For example, you could queue in pending changes and let them execute from only one thread, or keep the collection encapsulated and set up a visitor for iterating from other threads.
How come is volatile not enough? Can you elaborate on this point, please? I do not comprehend where the problem lies.
It isn't necessarily a problem? I am trying to lay out structure on a piece of paper, so I can't just use a profiler. I am also not too fond
of organizing it differently. The Collection is for connections to clients. Thread (A) is a listener, that is just supplying work for thread (B), which is doing work. This is to keep from blocking the listener.
If I were to queue in changes, then one thread would supply those and the other take them away. That's a whole new concurrency problem. Would that be solved with a ConcurrentLinkedQueue?
Regardless, I am not fond of doing that. It seems far too complicated.