Java threads and shared resources

It is safe for code to be called by multiple threads at the same time, which is called thread safety. If a piece of code is thread-safe, then it does not contain race conditions. Race conditions only occur when multiple threads update shared resources. Therefore it is important to know when Java threads execute shared resources.

Local variables

Local variables are stored in each thread's own stack. That means local variables are not shared between threads. That also means that all local primitive variables are thread-safe. Here's an example:

public void someMethod(){

  long threadSafeInt = 0;

  threadSafeInt++;
}

Local Object Reference

Local references to objects are a bit different. The reference itself will not be shared. However, a reference to this object cannot be stored on every thread's stack. All objects are stored in the shared heap.

If a locally created object does not escape the method in which it was created, it is thread-safe. In fact, you can also pass it to other methods, and as long as the methods of the passed object are not available to other threads.

Here is an example:

public void someMethod(){

  LocalObject localObject = new LocalObject();

  localObject.callMethod();
  method2(localObject);
}

public void method2(LocalObject localObject){
  localObject.setValue("value");
}

The LocalObject instance in this example cannot be returned from this method, It cannot be passed to other objects. That is accessible from outside the someMethod method. Each thread executing someMethod method will create its own LocalObject instance and assign it to the localObject reference. Therefore this usage is thread safe.

In fact, this entire someMethod method is thread-safe. Even if this localObject instance is passed as a parameter to other methods of the same class, or other classes, it is thread-safe to use.

The only exception, of course, is if one of these methods is called with a LocalObject as a parameter, storing the LocalObject instance in some way, allowing access from other threads.

Object member variables

Object member variables (fields) are stored on the heap together with the object. Therefore, if two threads call a method on the same object instance, and this method updates the object member variables, the entire method is not thread-safe. Here is an example:

public class NotThreadSafe{
    StringBuilder builder = new StringBuilder();

    public add(String text){
        this.builder.append(text);
    }
}

If two threads call the add method simultaneously on the same NotThreadSafe instance, it will cause a race condition. For example:

##

NotThreadSafe sharedInstance = new NotThreadSafe();

new Thread(new MyRunnable(sharedInstance)).start();
new Thread(new MyRunnable(sharedInstance)).start();

public class MyRunnable implements Runnable{
  NotThreadSafe instance = null;

  public MyRunnable(NotThreadSafe instance){
    this.instance = instance;
  }

  public void run(){
    this.instance.add("some text");
  }
}

#Note how the two MyRunnable instances share the same NotThreadSafe instance. Therefore, a race condition occurs when they call the add method.

However, if two threads call the add method simultaneously on different instances, it will not cause a race condition. Here is an example from the previous one, slightly modified:

new Thread(new MyRunnable(new NotThreadSafe())).start();
new Thread(new MyRunnable(new NotThreadSafe())).start();

Now each thread has their own instance of NotThreadSafe, so that they cannot call the add method will interfere with each other. This code has no race conditions. So, even if an object is not thread-safe, it can still be used in this way without causing a race condition.

Thread Control Overflow Rules

When trying to decide whether your code's access to a resource is thread-safe, you can use the following Rules:

If a resource is created, used and disposed within
the control of the same thread,
and never escapes the control of this thread,
the use of that resource is thread safe.

The resource can be any shared resource, like an object, array, file, database connection, socket, etc. In Java, you can't always destroy an object explicitly, so "destroyed" means the object is missing or has a null reference.

Even if an object's use is thread-safe, if that object points to a shared resource like a file or database, your application as a whole may not be Thread safe now. For example, if thread 1 and thread 2 each create their own database connections, connection 1 and connection 2, each using their own connection, are thread-safe. But the use of the database pointed to by this connection may not be thread-safe. For example, if two threads execute code like this:

check if record X exists
if not, insert record X

If two threads execute this at the same time, and they are checking this record On the record, there is a risk that they will all end up being plugged in. As shown below:

Thread 1 checks if record X exists. Result = no
Thread 2 checks if record X exists. Result = no
Thread 1 inserts record X
Thread 2 inserts record X

This will also happen on threads that operate on files or other shared resources. It is therefore important to distinguish whether an object controlled by a thread is a resource, or simply a reference to that resource (like a database connection).

The above is the content of Java threads and shared resources. For more related content, please pay attention to the PHP Chinese website (www.php.cn)!