synchronized-block | 易学教程

Why do we write Synchronized(ClassName.class)

阅读更多关于 Why do we write Synchronized(ClassName.class)

问题 I have a question in singleton pattern. In singleton pattern we write synchronized(ClassName.class){ // other code goes here } What is the purpose of writing ClassName.class ? 回答1: In a member method (non-static) you have two choices of which monitor (lock) to use: " this " and " my class's single static lock ". If your purpose is to coordinate a lock on the object instance, use " this ": ... synchronized (this) { // do critical code } or public synchronized void doSomething() { ... } However

What effect does the monitor object have in synchronized block?

阅读更多关于 What effect does the monitor object have in synchronized block?

问题 After hours of reading i am still struggling to understand what the monitor object exactly does. A demo to show what i mean: public class Demo { public static Bathroom bathroom = new Bathroom(); public static Kitchen kitchen = new Kitchen(); public static void main(String[] args) { (new Thread(new Roommate("bob"))).start(); (new Thread(new Roommate("john"))).start(); (new Thread(new Mom())).start(); } } class Bathroom { public void use(String who) { synchronized (Demo.kitchen) { System.out

Java synchronization and collections

阅读更多关于 Java synchronization and collections

问题 If a synchronized block of code contains an unsynchronized collection. Is the collection considered thread safe? If not, can you provide any practical scenarios where two threads could unsafely access the collection within the synced code? Thanks. 回答1: Only if ALL the code that access the collection is synchronized and they use the same "object" to synchronize it. For example, the code below would not be synchronized because they are synced to different objects. public class Foo { private

Synchronizing on an object and changing the reference

阅读更多关于 Synchronizing on an object and changing the reference

问题 Let's say I have an object as follows: Map<String, String> m = new HashMap<>(); Then I synchronize on this object as follows and change its reference: synchronize(m){ m = new HashMap<>(); } With this code, what happens to the lock on m? Is it still safe to update the new object represented by m? Or is the lock essentially on the old object? 回答1: From JLS 17.1: The synchronized statement (§14.19) computes a reference to an object; it then attempts to perform a lock action on that object's

Simplification of synchronized block in Java

阅读更多关于 Simplification of synchronized block in Java

问题 I'm having some trouble wrapping my head around the concept of synchronized blocks in Java. I feel I have understood synchronized methods well enough. So I thought of an analogy to help me understand synchronized blocks in terms of synchronized methods. Please let me know if this equivalence that I have proposed is correct. Also, I have only mentioned this for a non-static synchronized block for now. However, points on static synchronzied blocks are also welcome. public void method() { //code

AtomicBoolean vs synchronized block

阅读更多关于 AtomicBoolean vs synchronized block

I was trying to cut thread contention in my code by replacing some synchronized blocks with AtomicBoolean . Here's an example with synchronized : public void toggleCondition() { synchronized (this.mutex) { if (this.toggled) { return; } this.toggled = true; // do other stuff } } And the alternative with AtomicBoolean : public void toggleCondition() { if (!this.condition.getAndSet(true)) { // do other stuff } } Taking advantage of AtomicBoolean 's CAS property should be way faster than relying on synchronization so I ran a little micro-benchmark . For 10 concurrent threads and 1000000 iterations

Concurrency in Java using synchronized blocks not giving expected results

阅读更多关于 Concurrency in Java using synchronized blocks not giving expected results

问题 Below is a trivial java program. It has a counter called "cnt" that is incremented and then added to a List called "monitor". "cnt" is incremented by multiple threads, and values are added to "monitor" by multiple threads. At the end of the method "go()", cnt and monitor.size() should have the same value, but they don't. monitor.size() does have the correct value. If you change the code by uncommenting one of the commented synchronized blocks, and commenting out the currently uncommented one,

Concurrency in Java using synchronized blocks not giving expected results

阅读更多关于 Concurrency in Java using synchronized blocks not giving expected results

Below is a trivial java program. It has a counter called "cnt" that is incremented and then added to a List called "monitor". "cnt" is incremented by multiple threads, and values are added to "monitor" by multiple threads. At the end of the method "go()", cnt and monitor.size() should have the same value, but they don't. monitor.size() does have the correct value. If you change the code by uncommenting one of the commented synchronized blocks, and commenting out the currently uncommented one, the code produces the expected results. Also, if you set the thread count (THREAD_COUNT) to 1, the

Do we need to synchronize writes if we are synchronizing reads?

阅读更多关于 Do we need to synchronize writes if we are synchronizing reads?

I have few doubts about synchronized blocks. Before my questions I would like to share the answers from another related post Link for Answer to related question . I quote Peter Lawrey from the same answer. synchronized ensures you have a consistent view of the data. This means you will read the latest value and other caches will get the latest value. Caches are smart enough to talk to each other via a special bus (not something required by the JLS, but allowed) This bus means that it doesn't have to touch main memory to get a consistent view. If you only use synchronized, you wouldn't need

In java, return value within synchronized block seems like bad style. Does it really matter?

阅读更多关于 In java, return value within synchronized block seems like bad style. Does it really matter?

I have a Collections.synchronizedList of WeakReference, _components; I wrote something like the following, expecting the complier to complain: public boolean addComponent2(Component e) { synchronized (_components) { return _components.add(new WeakReference<Component>(e)); } } But the compiler is perfectly satisfied. Note that List.add() returns TRUE. So ok, any exit from a synchronized block releases the lock, but doesn't this LOOK strange? It's kind of like a "hole" in the block, similar to using return in a loop. Would you be happy maintaining code like this? It's absolutely fine - as is