Java Theory and Practice: describing thread safety

In Joshua Bloch's excellent effective Java programming Language Guide (see Resources), the title of item 52nd is "Document Thread Safety", in which he asks developers Record exactly what the class guarantees for thread security. Like most of the suggestions in Bloch, this is a very good suggestion that is repeatedly mentioned but rarely implemented (as Bloch in his programming puzzlers conversation "Don't write code like my Brother").

How many times have you looked at a class in Javadoc and guessed, "Is this class thread safe?" ” 。 Due to lack of clear records, readers may make improper assumptions about the thread security of a class. Perhaps they assume that a class that is not thread-safe is thread-safe (which is really bad!). Or assume that you can synchronize objects before calling a method of an object to get thread security (which may or may not be true, and, in the worst case, may only provide illusory thread security). In any case, it is best to specify in the document how the class behaves when an instance of a class is shared across multiple threads.

One example of this problem is that the Java.text.SimpleDateFormat class is not thread-safe, but this is not documented in Javadoc until the JDK is 1.4. How many developers mistakenly create static instances of SimpleDateFormat and use it in multiple threads without knowing whether their programs will run correctly under heavy load? Do not do such a thing to your customers or co-workers!

Write it down before you forget (or leave the company)

Be sure to record thread security The first time you write a class--it's much easier to access the class thread security requirements and behavior when you write it than it is a few months before you (or someone else) can look back. There will never be a clearer understanding of what happens in an implementation than when writing it. In addition, logging thread security while writing a class can keep your initial idea of thread security in mind because the maintainer wants to see the record as part of the description of the class.

If thread security is a two-dollar property of a class, you only need to record whether the class is thread-safe or thread-unsafe. But unfortunately, it's not that simple. If the class is not thread-safe, can you make it thread-safe by synchronizing each time you access the object of this class? Is there a sequence of operations that does not allow other threads to intervene, so that not only does the basic operation need to be synchronized, but also the composite operation is synchronized? Is there a state dependency between methods that contain a set of actions that need to be performed automatically? Developers need to master this information when they want to use a class in a concurrent application.

Defining Thread Security

Clearly defining thread security is surprisingly difficult, and most definitions seem to be completely self looping. To quickly search Google, you can find the following definition (or description) of the typical, but not much helpful, thread-safe code:

... Can be invoked from multiple programming threads without unnecessary interaction between threads.

... Can be invoked at the same time by multiple threads without requiring any action on the caller side.

With this definition, it's not surprising that we're so confused about thread security. These definitions are not much better than saying that "a class is thread-safe when it can be invoked by multiple threads", of course, it does, but it does not help us distinguish between a thread-safe class and a thread-unsafe class. What is the meaning of security?

In fact, all thread-safe definitions have a loop of some kind of program, because it must conform to the specification of the class--this is an informal loosely described description of the function of the class, its side effects, which states are valid and invalid, invariants, preconditions, post conditions, and so on (the state of the object given by the specification) Constraints apply only to externally visible states, that is, those States that can be seen by calling their public methods and accessing their public fields, and not the internal state represented in their private fields.