Home/ Questions/Q 60703
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T18:12:13+00:00

If I create classes, that are used at the moment only in a single

  • 0

If I create classes, that are used at the moment only in a single thread, should I make them thread-safe, even if I don’t need that at the moment? It could be happen, that I later use this class in multiple threads, and at that time I could get race conditions and may have a hard time to find them if I didn’t made the class thread-safe in the first place. Or should I make the class not thread-safe, for better performance? But premature optimization is evil.

Differently asked: Should I make my classes thread-safe if needed (if used in multiple threads, otherwise not) or should I optimize this issue then needed (if I see that the synchronization eats up an important part of processing time)?

If I choose one of the both ways, are there methods to reduce the disadvantages? Or exists a third possibility, that I should use?

EDIT: I give the reason this question came up to my mind. At our company we have written a very simple user-management that writes the data into property-files. I used it in a web-app and after some work on it I got strange errors, that the user-management forgot about properties of users(including name and password) and roles. That was very annoying but not consistently reproducible, so I think it was race condition. Since I synchronized all methods reading and writing from/on disk, the problem disappeared. So I thought, that I probably could have been avoided all the hassle, if we had written the class with synchronization in the first place?

EDIT 2: As I look over the tips of Pragmatic Programmer, I saw tip #41: Always Design for Concurrency. This doesn’t say that all code should be thread-safe, but it says the design should have the concurrency in mind.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Start from the data. Decide which data is explicitly shared and protect it. If at all possible, encapsulate the locking with the data. Use pre-existing thread-safe concurrent collections.

    Whenever possible, use immutable objects. Make attributes final, set their values in the constructors. If you need to ‘change’ the data consider returning a new instance. Immutable objects don’t need locking.

    For objects that are not shared or thread-confined, do not spend time making them thread-safe.

    Document the expectations in the code. The JCIP annotations are the best pre-defined choice available.

    • 0