thread safety with two synchronized methods, one static, one non static

Question

If a class has only two synchronized methods (both either static or non static), the class is considered to be thread safe. What if one of the methods is static and one non static? Is it still thread safe, or bad things can happen if multiple threads call the methods?

There are some similar threads like static synchronized and non static synchronized methods in threads which describe the method calls are not blocking each other. But I am curious to know whether bad things in the world of thread safety (like inconsistent state, race condition, etc) can happen or not.

Edit 1:
Since static methods can't call non static methods, there should be no thread conflict from this side. On the other hand if a non static method calls the static one, it has to acquire the class lock. Which would be still thread safe. So by just having two methods (one static one none) I don't see any thread conflict. Is that right? In other words the only case I can see to have an issue is when the non static method accesses some static variables. But if all accesses are done through methods then I don't see any issues with thread safety. These were my thoughts. I am not sure whether I am missing something here since I am a little bit new to java concurrency.

Answer 1

In Java, the following:

public class MyClass
{
    public synchronized void nonStaticMethod()
    {
        // code
    }

    public synchronized static void staticMethod()
    {
        // code
    } 
}

is equivalent to the following:

public class MyClass
{
    public void nonStaticMethod()
    {
      synchronized(this)
      {
          // code
      }
    }

    public void static staticMethod()
    {
      synchronized(MyClass.class)
      {
          // code
      }
    } 
}

As you see, static methods use this as monitor object, and non-static methods use class object as monitor.

As this and MyClass.class are different objects, static and non-static methods may run concurrently.

---

To "fix" this, create a dedicated static monitor object and use it in both static and non-static methods:

public class MyClass
{
    private static Object monitor = new Object(); 

    public void nonStaticMethod()
    {
      synchronized(monitor)
      {
          // code
      }
    }

    public static void staticMethod()
    {
      synchronized(monitor)
      {
          // code
      }
    } 
}

Answer 2

What if one of the methods is static and one non static? Is it still thread safe, or bad things can happen if multiple threads call the methods?

Bad things can happen.

The static method will lock on the class monitor. The instance method will lock on the instance monitor. Since two different lock objects are in use, both methods could execute at the same time from different threads. If they share state (ie the instance method accesses static data) you will have problems.

Answer 3

What if one of the methods is static and one non static? Is it still thread safe, or bad things can happen if multiple threads call the methods?

Synchronization works with monitor (locks) that is taken on object.

In case of static method it's object of Class's class and in case of instance method it's this or calling object.

Since both the objects are different hence both synchronized static and non-static method will not block each other in case of multi-threading. Both the methods will execute simultaneously.

Answer 4

What if one of the methods is static and one non static

Yes.. Bad things can happen. Because if you synchronize on a static method, then you will be locking on the monitor of the Class object not on the class instance ie, you will be locking on MyClass.class . Whereas when you are synchronizing on an instance (non-static) method, you will actually be locking on the current instance ie, this . So, you are locking on two different objects. So, the behaviour will be undefined and certainly not correct .

PS : In multi-threading, as a rule of thumb, please remember - If bad things can happen, they will happen .

Answer 5

What if ... Is it still thread safe?

Can't answer that question without a complete example. The question of thread safety is never a question about methods: It's a question about corruption of data structures and about liveness guarantees. Nobody can say whether a program is thread safe without knowing what all of the different threads do, what data they do it to, and how they coordinate (synchronize) with one another.