Question

I was thinking about creating a class (like String, StringBuffer etc). This can be used in single-threaded as well as in multi-threaded environments. I do not know which kind of environment a developer might be using it. Anticipating the worst-case, I can synchronize.

But,
1. Synchronization takes a performance hit.
2. Without synchronization, it is not thread-safe.

So, I have two options.

1. Leave the class unsynchronized – but the developer using this class needs to synchronize it whenever appropriate.
2. Have all synchronized methods – and take a performance hit.

I have seen that many (if not all. for eg, ArrayList over Vector) classes in Java have evolved to take the first approach. What are some of the things I need to consider before deciding on these two options for my class?

Or to put it in a different way, should I use “public synchronized void bar()” over “public void bar()” only when I know for sure that bar can be used in a multi-threaded environment and should not be run at the same time?

EDIT So, clearly I have mis-used the word “utility class” in the heading. Thanks, Jon Skeet, for pointing it out. I have removed the world “utility” from the heading.

To give an example, I was thinking about a class like, say, Counter. Counter is just as an example. There are other ways to implement Counter. But this question is about synchronization. A Counter object keeps track of how many times something has been done. But it can possibly be used in single-threaded or multi-threaded environments. So, how should I handle the problem of synchronization in Counter.

Answer 1

What I think of as a utility class – typically a grab-bag of vaguely-related public static methods – rarely requires any synchronization. Unless the class maintains some mutable state, you’re usually absolutely fine.

Of course, if you take parameters which are themselves shared between threads and contain mutable state, you may need synchronization – but that should be for the caller to decide, usually.

If you mean something else by “utility class” it would be good to know what you mean. If it’s a class with no mutable state (but perhaps immutable state, set at construction) then it’s typically fine to share between threads.

If it has mutable state but isn’t explicitly about threading, I would typically not put any synchronization within that class, but document that it’s not thread-safe. Typically the callers would need to synchronize multiple operations using multiple objects anyway, so “method at a time” synchronization doesn’t typically help.

If it’s a class which is all about threading (e.g. something to manage producer/consumer queues) then I would try to make it thread-safe, but document what you mean by that. I’d encourage you not to make the methods themselves synchronize, but instead synchronize on a private final field which is only used for synchronization; that way your class will contain the only code which could possibly synchronize on that object, making it easier to reason about your locking.

You should almost certainly not make these decisions on the basis of performance. Correctness and easy of is far more important than performance in most cases.