Java 线程：object 有同步和不同步两种方法

Question

suppose there are 2 threads used in this demo.Suppose increment() code block executes first and acquires the monitor on the current object.does other thread will not be able to execute the method decrement() ? .

can anyone help me understand?

if I ran the application, other thread able to execute non-synchronized method even though is lock on the object hold by thread that sleeps 10000 ms .

package com.learn.threads;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class ThreadDemo {

    int sharedVariable;

    public ThreadDemo(int sharedVariable) {
        this.sharedVariable = sharedVariable;
    }


    public synchronized void increment() throws InterruptedException {
        Thread.sleep(10000);
        this.sharedVariable++;

    }

    public void decrement() throws InterruptedException {
        this.sharedVariable--;

    }


    public static void main(String[] args) throws InterruptedException {

        ThreadDemo task = new ThreadDemo(0);

        ExecutorService incrementExecutorService = Executors.newFixedThreadPool(2);
        for (int i = 0; i < 6; i++) {
            incrementExecutorService.submit(() -> {
                try {
                    task.increment();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            });
            Thread.sleep(5000);
            incrementExecutorService.submit(() -> {
                try {
                    task.decrement();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            });

        }
        Thread.sleep(35000);
        incrementExecutorService.shutdown();
        System.out.println(task.sharedVariable);

    }
}

Answer 1

No, it won't.

1. synchronized on a method is just syntax sugar for wrapping the entire body of the method in synchronized (X) {} , where X is this for instance methods and YourClass.class for static ones. It is a severe design error unless you document the locking behaviour of your class if you do this - anytime you lock on stuff other code could get a reference to ( this and YourClass.class are usually public), you need to document this, and endeavour to support what you document in future v ersion.

2. synchronized interacts with other synchronized blocks on the same reference, and on thatRef.wait/notify/notifyAll() and nothing else . It has zero effect on its own, you always need 2 different threads both hitting a synchronized block, synchronizing on the same thing, or it does nothing useful.

The code snippet as pasted is broken: If some thread calls decrement() , other threads may or may not observe this, as no CBCA relationship is established. Any code that reads sharedVariable needs to lock on ThreadDemo , and the decrement method needs to gain a synchronized attribute.

Note that the job of having an incrementable/decrementable thing already exists: AtomicInteger , you should be using that instead if this is your actual intent (but I'm assuming you wrote this merely as an example).

NB: The java memory model is best understood as an evil coin. Evil in that it is out to mess with you: To have code that works great every time and in all your tests, and the first week you put it live on the production servers, and then just as that important customer gets a demo, it breaks. You must write code such that the VM never flips that coin (or rather, that the results of the flip do not affect your code), and there is no easy way to know that the evil coin is being flipped. Threading is very difficult to get right, yup. Why do you think most multithreaded code out in the real world does all inter-thread communication via a message bus or transactional database? The coin is flipped anytime any code touches any field anywhere, and the result of the coin decides whether the thread uses a local clone copy of that field, or if it reads from the shared copy. Thus, sharedVariable-- might result in a decrement that only your thread can see, or all threads can see, depending on the result of the evil coin. If what your code does depends on the flip, you messed up, and your tests aren't going to catch it. You can avoid the coin flip by establishing a comes-before relationship between sharedVariable-- and whatever cod reads sharedVariable . synchronized is one of a few ways to establish such a relationship. Search the web for 'java memory model' 'synchronized' for more info - but note that this is very complex stuff.