Handling Static Variables in Multithreaded Java Program

Handling static variables in multithreaded java program

Finally found a way using this link:

https://dmitrykrivenko.blogspot.com/2016/07/threadlocal-and-inheritablethreadlocal.html

Used InheritableThreadLocal instead of ThreadLocal. In this way, I'm able to access the data in child threads as well now.

public class DriverFactory {

private static final ThreadLocal<Map<String, String>> driverData = new InheritableThreadLocal<>();


public static String getDriverData(String key){
    return driverData.get().get(key);
}   

public static void setDriverData(Map<String, String> driver){
    driverData.set(driver);
}

}

static variables in multithreading

static makes no sense in Multi-Threading.

Im afraid you are making the reverse statement. Static variable is a shared resource, which can be used to exchange some information among different threads. And we need to be careful while accessing such a shared resource. Hence, we need to make sure that the access to static variables in multi-threaded environment is synchronized.

every thread has its own stack

This is a correct statement. Each thread has its own stack but they share the process heap. Stack holds only the local variables and not the variables on the heap. Static variables are stored in the PermGen section of the heap and hence the access to them should be well guarded.

Static variables and multithreading in java

Static fields gave one value per class-loader.

If you want a per-thread value, make a static ThreadLocal<T>.

Java Multithread Access Static Variable

Wrap the static variable in a synchronized method and call the method as you like

public static synchronized void method1(){
//Whatever
}

public static synchronized void method2(){
//Whatever again
}

Note that there are other ways to synchronize access to a method. They are considered more efficient in environments busy threads accessing the same methods.

Check the ReentrantLock class. There are also answers for when to use synchronized and RentrantLock and many more information that could be found through google.

Also as peter's answer and muel's comment suggests. Marking the boolean variable as volatile should be helpful. volatile boolean variables will NOT cache it's initial value (false or true). The JVM could do that occasionally which could be unexpected by the programmer.

Are static variables shared between threads?

There isn't anything special about static variables when it comes to visibility. If they are accessible any thread can get at them, so you're more likely to see concurrency problems because they're more exposed.

There is a visibility issue imposed by the JVM's memory model. Here's an article talking about the memory model and how writes become visible to threads. You can't count on changes one thread makes becoming visible to other threads in a timely manner (actually the JVM has no obligation to make those changes visible to you at all, in any time frame), unless you establish a happens-before relationship.

Here's a quote from that link (supplied in the comment by Jed Wesley-Smith):

Chapter 17 of the Java Language Specification defines the happens-before relation on memory operations such as reads and writes of shared variables. The results of a write by one thread are guaranteed to be visible to a read by another thread only if the write operation happens-before the read operation. The synchronized and volatile constructs, as well as the Thread.start() and Thread.join() methods, can form happens-before relationships. In particular:

• Each action in a thread happens-before every action in that thread that comes later in the program's order.

• An unlock (synchronized block or method exit) of a monitor happens-before every subsequent lock (synchronized block or method entry) of that same monitor. And because the happens-before relation is transitive, all actions of a thread prior to unlocking happen-before all actions subsequent to any thread locking that monitor.

• A write to a volatile field happens-before every subsequent read of that same field. Writes and reads of volatile fields have similar memory consistency effects as entering and exiting monitors, but do not entail mutual exclusion locking.

• A call to start on a thread happens-before any action in the started thread.

• All actions in a thread happen-before any other thread successfully returns from a join on that thread.

---

Related Topics