mahajan amit wrote:
Is this static variable thread safe?
Seetharaman Venkatasamy wrote:
Seetharaman Venkatasamy wrote:
mahajan amit wrote:
Is this static variable thread safe?
No, it is not thread safe. you can see this behavior to write one java program
1.start two thread on single object
2. declare one static int in that object
3. and loop like below in your run()
you need proper synchronization for above code.
<edit>William beaten me ;)</edit>
mahajan amit wrote:Actually the question i am asking is if all the methods accessing this static variable are also static.
these static methods and variables will be stored in class memory right?
Does it gives any advantage for thread safety.
I have seen one application where this feature is used for skipping synchronization.
Anyways what was the result of your testing.
Can you test with static methods?
if a field is set in a static initializer, it is guaranteed to be made visible, correctly, to any thread that accesses that class.
"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5
Chris Hurst wrote:A bit picky ... but static variables have a albeit small advantage around initialization ..
if a field is set in a static initializer, it is guaranteed to be made visible, correctly, to any thread that accesses that class.
.. over a non static , so I wouldn't say no difference just not a lot.
mahajan amit wrote:Static Method + Data -> Stack
Objects -> Heap
Thread 1 -> Read static -> copy stack static value to Heap
-> perform Read Write
-> Save changes to stack
Thread 2 -> Read static -> copy stack static value to Heap
-> perform Read Write
-> Save changes to stack
Thread 3 -> Read static -> copy stack static value to Heap
-> perform Read Write
-> Save changes to stack
In case all methods are also static they will always be copied to heap and get new memory.
Does it makes my Question clearer?
Any program some one can write to deny it?
Jeff Verdegan wrote:
mahajan amit wrote:Static Method + Data -> Stack
...
The only thing that's on the stack is local variables--primitives and references.
Steve
Jeff Verdegan wrote:
The only thing that's on the stack is local variables. Note that a variable in Java holds either a primitive or a reference, but never an object. So what's on the stack is only local variables holding primitive values and local variables holding null or holding reference values that point to objects that are on the heap.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Jelle Klap wrote:
Jeff Verdegan wrote:
The only thing that's on the stack is local variables. Note that a variable in Java holds either a primitive or a reference, but never an object. So what's on the stack is only local variables holding primitive values and local variables holding null or holding reference values that point to objects that are on the heap.
I don't mean to add to the confusion, but the HotSpot server VM has been able to perform escape analysis since Java 6u14, which could result in stack allocation of objects - or scalar replacement, but this was about objects on the stack - if I remember correctly.
Jeff Verdegan wrote:I didn't think that it was in 6. I thought it was talked about for 7, but I never found out if that actually made it into the spec, and if so, if Oracle's JVM actually made use of it.
Optimization Using Escape Analysis
The -XX:+DoEscapeAnalysis option directs HotSpot to look for objects that are created and referenced by a single thread within the scope of a method compilation. Allocation is omitted for such non-escaping objects, and their fields are treated as local variables, often residing in machine registers. Synchronization on non-escaping objects is also elided.
After escape analysis, the server compiler eliminates scalar replaceable object allocations and associated locks from generated code. The server compiler also eliminates locks for all non-globally escaping objects. It does not replace a heap allocation with a stack allocation for non-globally escaping objects.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |