Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is there any compile-time mechanism in Java to attempt to ensure that use of a particular class is always synchronized?

We have a class in our codebase currently that uses the synchronized keyword at the method level to ensure data consistency in multithreaded operations. It looks something like this:

public class Foo
{
   public synchronized void abc() { ... }

   public synchronized void def() { ... }

   //etc.
}

The nice thing about this is that anyone using the class gets the synchronization for free. When you create an instance of Foo, you don't have to remember to access it inside of a synchronized block or anything like that.

Unfortunately, it seems that synchronization at the method level isn't going to cut it anymore. Instead we're going to have to start synchronizing on Foo itself. I don't think anything like java.util.concurrent.AtomicReference is going to cut it either. I want to make sure no one else touches an instance of Foo while a particular (and possibly somewhat lengthy) operation is going on. So now we're going to have blocks like this in the code:

Foo foo = new Foo(); //this got created somewhere

//somewhere else entirely
synchronized(foo)
{
   //do operation on foo
   foo.doStuff();
   foo.doOtherStuff();
}

So the main thing I'm worried about is that a few developers and I share this code. Foo objects are fairly ubiquitous. Since we're not getting the synchronization for free any more at the method level, we must ALWAYS remember to access a Foo object within a synchronized block.

So my question is, is there any mechanism (built-in or third party) in Java to allow me to generate warnings or errors at compile-time if an instance of Foo is accessed outside of a synchronized block?

Ideally it would be something I can either do to the class declaration (made up example below):

@EnsureSynchronized
public class Foo
{
   //etc.
}

Or something I could do when I declare instances of Foo (made up example below):

@EnsureSynchronized
private Foo foo;

I know if I really wanted to I could probably write a custom FindBugs or PMD rule to do this, but I was hoping something like this already existed.

So I ask you, SO community, if you were in this situation, how would you try to ensure that Foo objects are only ever accessed and modified inside synchronized blocks?

like image 883
Brent Writes Code Avatar asked Oct 13 '11 15:10

Brent Writes Code


People also ask

How does one ensure thread Synchronisation such that all threads wait until all threads arrive?

Barriers. Barriers are a synchronization mechanism that can be used to coordinate multiple threads working in parallel. A barrier allows each thread to wait until all cooperating threads have reached the same point, and then continue executing from there.

Can static synchronized methods and instance synchronized methods exist in the same class?

Synchronized static methods are synchronized on the class object of the class the synchronized static method belongs to. Since only one class object exists in the Java VM per class, only one thread can execute inside a static synchronized method in the same class.

What are the important methods that are used in Java synchronization?

It can be achieved by using the following three ways: By Using Synchronized Method. By Using Synchronized Block. By Using Static Synchronization.

How can we ensure that instance of this class can be safely used by multiple threads?

Using Volatile keyword A volatile keyword is a field modifier that ensures that the object can be used by multiple threads at the same time without having any problem. volatile is one good way of ensuring that the Java program is thread-safe.


1 Answers

Findbugs is pretty good at finding inconsistent synchronization so as long as you have some code that synchronizes all accesses to an object, and run findbugs, it should alert you to failures to sync.

A typical bug matching this bug pattern is forgetting to synchronize one of the methods in a class that is intended to be thread-safe.

You can select the nodes labeled "Unsynchronized access" to show the code locations where the detector believed that a field was accessed without synchronization.

Note that there are various sources of inaccuracy in this detector; for example, the detector cannot statically detect all situations in which a lock is held. Also, even when the detector is accurate in distinguishing locked vs. unlocked accesses, the code in question may still be correct.

If that isn't sufficient, you can always annotate with net.jcip.annotations.NotThreadSafe which findbugs recognizes.

From Chapter 10. Annotations :

FindBugs also supports the following annotations:

  • ...
  • net.jcip.annotations.NotThreadSafe
like image 172
Mike Samuel Avatar answered Nov 16 '22 00:11

Mike Samuel