Is a static member of a class present as only a single instance per process or thread? Meaning does each thread has its own copy of the static member variable of the class?
My guess is per process, am I correct?
Asked
Active
Viewed 3.4k times
28
-
Reminder to accept an answer if it was helpful. – Gray Dec 01 '21 at 15:01
7 Answers
47
Is a static member of a class present as only a single instance per process or thread?
static fields have one value per class-loader but I think the meat of your question is in the following:
each thread has its own copy of the static member variable of the class
Each thread may have its own copy of the field in its own local memory space/cache unless the field has been marked with volatile which forces the field to be surrounded with a memory barrier which causes a memory synchronization on each access/update.
Without volatile, any updates and reads to a static field will be made to local thread storage and only updated whenever a thread crosses a memory barrier. Without the memory barriers, there are no guarantees around the order of data operations and when the updates will be shared with other threads.
Here's a decent page about the Java memory model and a good overview of some of the challenges.
Gray
- 115,027
- 24
- 293
- 354
-
1
-
2Actually, each *processor* ***may*** have it's own copy. Though "virtual processors", et al, further muddy the water. – Hot Licks Apr 03 '14 at 22:05
-
is there a difference between multi-threading of a single processor and multi-threading of multiple processors? – OhadR Jan 05 '17 at 15:10
-
1Yes and no @OhadR. Certainly there are implications around memory sharing if there aren't multiple processors but a good programmer would not rely on hardware specifics as a way to simplify the memory model of their code written for multiple threads. – Gray Jan 05 '17 at 16:10
-
@Gray thanks; but is it possible that in an env with many processors, a static variable in a class will have different values per each processor? class A{static Integer i;} A.i of processor X != A.i of processor Y? – OhadR Jan 05 '17 at 20:19
-
-
got it. basically, the answer is "yes". it is possible that in an env with many processors, a static variable in a class will have different values per each processor. class A{static Integer i;} A.i of processor X != A.i of processor Y? – – OhadR Jan 06 '17 at 07:18
-
31
Static fields gave one value per class-loader.
If you want a per-thread value, make a static ThreadLocal<T>.
SLaks
- 868,454
- 176
- 1,908
- 1,964
-
11Yep, and for mere mortals "per class-loader" means "per JVM process". Technically, the same class loaded by two different class loaders results in two different classes, even though they have the same name and may have been loaded from the exact same class file. – Hot Licks Apr 03 '14 at 22:02
11
There is one copy of static variable per class-loader that loaded this class. This more-or-less means per-process, however you need to be aware of the difference.
E.g. when two web-apps have the same class bundled, the class will be loaded twice, thus having two copies of the same static field.
If you need a variable having independent value on a thread basis, have a look at ThreadLocal.
Tomasz Nurkiewicz
- 334,321
- 69
- 703
- 674
4
http://docs.oracle.com/javase/tutorial/java/nutsandbolts/variables.html
Class Variables (Static Fields) A class variable is any field declared with the static modifier; this tells the compiler that there is exactly one copy of this variable in existence, regardless of how many times the class has been instantiated. A field defining the number of gears for a particular kind of bicycle could be marked as static since conceptually the same number of gears will apply to all instances. The code static int numGears = 6; would create such a static field. Additionally, the keyword final could be added to indicate that the number of gears will never change.
Threads have no bearing on this. (The classloader on the other hand does. If you're using multiple classloaders in your application, however, you are probably at a point where you understand that).
Brian Roach
- 76,169
- 12
- 136
- 161
-
3"Threads have no bearing on this" is misleading, see Gray's answer – Blake Miller Apr 01 '13 at 22:27
2
The issue with threading is this: The "10,000 foot" view of Java memory is that there is one single chunk of memory that is shared by all classes, all objects, all class loaders, and all threads in the running JVM -- whatever is accessible from one place in the code is accessible everywhere else (given an appropriate reference). The only exception is registers and the execution stack, which are conceptually on a per-thread basis.
This works pretty darn well with a single processor, where threads take turns executing in a single set of registers and ALUs and such. But most modern computers have multiple processors, so that several threads can execute literally at the same time. If these processors had to all reference the same physical memory then (based on real-life experience) you'd only be able to get about 1.5x performance improvement with 4 processors, and it would degenerate from there.
So "cache" is used, so that each processor has its own little private copy of bits and pieces of the larger memory. Most of the time the processors are addressing entirely different areas of memory, so this works fine, but occasionally (as when dealing with some "shared" object) they must "fight" over the same set of bytes.
The solution is to establish protocols so that no two processors will attempt to modify the same storage locations at the same time (or nearly the same) and to assure that one processor's changed get "flushed" to main store and other processors be made aware of the changes and advised to reload their view of the modified data.
But it's (incredibly) inefficient to do this after every operation (and, quite frankly, hardware designers have dodged the issue to a significant degree and pushed more of this work onto the software than is probably justified). So schemes are used such that the flush and reload of data only occurs on certain "boundaries", or when certain special types of references are done.
Note that all this has absolutely nothing to do with whether a variable is "static" or not, nor does it really have to do with whether objects are "immutable". It's inherent in the modern multi-processor hardware architecture, combined with the Java thread model.
Hot Licks
- 47,103
- 17
- 93
- 151
0
As SLaks suggested its one per JVM, but beware that two threads holding lock on same static reference will block each other, reason being there is only one such reference per vm. But they wont block threads referring to instance variables.
mprabhat
- 20,107
- 7
- 46
- 63
-
That's not true; if two instance variables refer to the same object, they'll still block. Also, he didn't ask about locks. – SLaks Dec 08 '11 at 14:19
-
I meant to say Threads blocking on static wont block threads trying to acquire lock on instance – mprabhat Dec 08 '11 at 15:07
-
That's not true. It depends not on the declaration of the field, but on what object the field refers to. – SLaks Dec 08 '11 at 15:07
-
-
-
static and instance lock will always differ from each other , somethin.class and this will never be same, so they will never block each other, thats what I meant if you disagree please explain – mprabhat Dec 08 '11 at 15:11
-
You're talking about `synchronized` methods. I'm talking about explicitly locking on an object reference. – SLaks Dec 08 '11 at 18:15
-2
Actually class variable corresponds to the class, in it shares only single memory, so changes made by each instance of class can change the class variable.
Jimshad Abdulla
- 167
- 2
- 8
-
1This is really not true for a number of different reasons. "shares only single memory" is as best misleading. – Gray Dec 08 '11 at 14:39