Java同步

volatile[About] => synchronized

synchronized块在Java中是多线程中的监视器。同一对象/类的同步块只能由单个线程执行，其他的都在等待。它可以帮助解决竞赛状况。

Java 5通过支持happens-before扩展了同步[关于]

监视器的解锁(同步块或方法退出)发生在同一监视器的每个后续锁定(同步块或方法进入)之前。

下一步是java.util.concurrent

synchronized关键字是什么?

线程主要通过共享对字段和引用字段所引用的对象的访问进行通信。这种通信形式非常高效，但可能会产生两种错误:线程干扰和内存一致性错误。防止这些错误所需的工具是同步。

同步块或方法可以防止线程干扰，并确保数据是一致的。在任何时候，只有一个线程可以通过获得锁来访问同步块或方法(临界区)。其他线程将等待锁释放来访问临界区。

方法何时同步?

将synchronized添加到方法定义或声明时，方法是同步的。您还可以在方法中同步特定的代码块。

它在语法上和逻辑上意味着什么?

这意味着只有一个线程可以通过获得锁来访问临界区。除非这个线程释放这个锁，否则所有其他线程将不得不等待获得一个锁。他们不能在没有锁的情况下进入临界区。

这不是魔法能办到的。程序员的职责是识别应用程序中的关键部分并相应地保护它。Java提供了一个框架来保护你的应用程序，但是在哪里以及保护哪些部分是程序员的责任。

更多细节，请参阅java文档页

内在锁和同步:

同步是围绕一个称为内在锁或监视器锁的内部实体构建的。内在锁在同步的两个方面都发挥作用:强制对对象状态的独占访问，并建立对可见性至关重要的happens-before关系。

每个对象都有一个与之相关的内在锁。按照惯例，需要独占和一致访问对象字段的线程必须在访问对象字段之前获得对象的内在锁，然后在使用完对象字段时释放内在锁。

线程在获得锁和释放锁之间拥有内在锁。只要一个线程拥有一个内在锁，其他线程就不能获得相同的锁。另一个线程在试图获取锁时将阻塞。

当线程释放一个内在锁时，在该操作和后续获得的任何相同锁之间建立happens-before关系。

使方法同步有两个效果:

首先，对同一对象的同步方法的两次调用不可能交织。

当一个线程正在为一个对象执行同步方法时，所有为同一对象调用同步方法的其他线程将暂停执行，直到第一个线程处理完该对象。

其次，当同步方法退出时，它自动与同一对象的同步方法的任何后续调用建立happens-before关系。

这保证了对对象状态的更改对于所有线程都是可见的。

寻找同步的其他替代方案:

避免在Java中同步(这)?

你可以把它想象成一个转门，就像你在足球场看到的那样。有平行的人群想要进入，但在旋转门他们是“同步的”。一次只能有一个人通过。所有想要通过的人都可以，但他们可能要等到他们能够通过。

同步法等效于正常方法 同步语句(使用此语句)

class A {
    public synchronized void methodA() {
        // all function code
    }

    equivalent to

    public void methodA() {
        synchronized(this) {
             // all function code
        }
    } 
}

同步静态方法等价于Synchronized语句(使用类)

class A {
    public static synchronized void methodA() {
        // all function code
    }

    equivalent to

    public void methodA() {
        synchronized(A.class) {
             // all function code
        }
    } 
}

同步语句(使用变量)

class A {
    private Object lock1 = new Object();

    public void methodA() {
        synchronized(lock1 ) {
             // all function code
        }
    } 
}

对于同步，我们有同步方法和同步语句。然而，同步方法类似于同步语句，所以我们只需要理解同步语句。

基本上，我们会有

synchronized(object or class) { // object/class use to provides the intrinsic lock
   // code 
}

这里有2个想法，有助于理解同步

每个对象/类都有一个与之相关的内在锁。 当线程调用同步语句时，它会自动获取同步语句对象的内在锁，并在方法返回时释放锁。只要一个线程拥有一个内在锁，其他线程就不能获得相同的锁=>线程安全。

= > 当线程a调用synchronized(this){// code 1} =>时，所有synchronized(this)的块代码(类内)和所有synchronized的正常方法(类内)都被锁定，因为是SAME锁。它将在线程A解锁("// code 1"完成)后执行。

此行为类似于synchronized(变量){// code 1}或synchronized(类)。

SAME LOCK =>锁(不依赖于哪个方法?或者哪些陈述?)

使用同步方法还是同步语句?

我更喜欢同步语句，因为它更易于扩展。例如，在将来，你只需要同步方法的一部分。例如，你有两个synchronized方法，它们之间没有任何关联，但是当一个线程运行一个方法时，它会阻塞另一个方法(它可以通过使用synchronized(一个变量)来防止)。

然而，应用同步方法很简单，代码看起来很简单。对于某些类，只有一个同步方法，或者类中所有同步方法彼此相关=>，我们可以使用同步方法使代码更短，更容易理解

Note

(它与同步无关，它是对象与类或非静态与静态之间的区别)。

当你使用synchronized或普通方法或synchronized(this)或synchronized(非静态变量)时，它将基于每个对象实例进行同步。 当你使用synchronized或静态方法或synchronized(类)或synchronized(静态变量)时，它将基于类进行同步

参考

https://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html https://docs.oracle.com/javase/tutorial/essential/concurrency/locksync.html

希望能有所帮助

What the other answers are missing is one important aspect: memory barriers. Thread synchronization basically consists of two parts: serialization and visibility. I advise everyone to google for "jvm memory barrier", as it is a non-trivial and extremely important topic (if you modify shared data accessed by multiple threads). Having done that, I advise looking at java.util.concurrent package's classes that help to avoid using explicit synchronization, which in turn helps keeping programs simple and efficient, maybe even preventing deadlocks.

ConcurrentLinkedDeque就是这样一个例子。与命令模式一起，它允许通过将命令填充到并发队列中来创建高效的工作线程——不需要显式同步，不可能发生死锁，不需要显式sleep()，只需通过调用take()轮询队列。

简而言之:“内存同步”隐式地发生在线程启动、线程结束、读取volatile变量、解锁监视器(留下同步块/函数)等时候。这种“同步”影响(在某种意义上“刷新”)在该特定操作之前完成的所有写操作。在前面提到的ConcurrentLinkedDeque的情况下，文档“说”:

内存一致性影响:与其他并发集合一样， 对象放入线程之前的操作 ConcurrentLinkedDeque访问之后的happens -before操作 或者从另一个ConcurrentLinkedDeque中删除该元素 线程。

这种隐式行为在某种程度上是有害的，因为大多数没有太多经验的Java程序员会因此而得过其实。然后突然被这个线程绊倒，因为Java在生产中没有做它“应该”做的事情，因为有不同的工作负载——并且很难测试并发性问题。

Synchronized的意思是，如果在特定对象上使用Synchronized块，那么与单个对象关联的多个线程可以防止脏读写。为了让你更清楚，让我们举个例子:

class MyRunnable implements Runnable {
    int var = 10;
    @Override
    public void run() {
        call();
    }

    public void call() {
        synchronized (this) {
            for (int i = 0; i < 4; i++) {
                var++;
                System.out.println("Current Thread " + Thread.currentThread().getName() + " var value "+var);
            }
        }
    }
}

public class MutlipleThreadsRunnable {
    public static void main(String[] args) {
        MyRunnable runnable1 = new MyRunnable();
        MyRunnable runnable2 = new MyRunnable();
        Thread t1 = new Thread(runnable1);
        t1.setName("Thread -1");
        Thread t2 = new Thread(runnable2);
        t2.setName("Thread -2");
        Thread t3 = new Thread(runnable1);
        t3.setName("Thread -3");
        t1.start();
        t2.start();
        t3.start();
    }
}

我们已经创建了两个MyRunnable类对象，runnable1与线程1和线程3共享，而runnable2仅与线程2共享。 现在，当t1和t3启动时没有使用synchronized, PFB输出表明线程1和线程3同时影响var值，而对于线程2,var有自己的内存。

Without Synchronized keyword

    Current Thread Thread -1 var value 11
    Current Thread Thread -2 var value 11
    Current Thread Thread -2 var value 12
    Current Thread Thread -2 var value 13
    Current Thread Thread -2 var value 14
    Current Thread Thread -1 var value 12
    Current Thread Thread -3 var value 13
    Current Thread Thread -3 var value 15
    Current Thread Thread -1 var value 14
    Current Thread Thread -1 var value 17
    Current Thread Thread -3 var value 16
    Current Thread Thread -3 var value 18

使用Synchronzied，线程3在所有场景中等待线程1完成。有两个锁，一个在runnable1上，由线程1和线程3共享，另一个在runnable2上，仅由线程2共享。

Current Thread Thread -1 var value 11
Current Thread Thread -2 var value 11
Current Thread Thread -1 var value 12
Current Thread Thread -2 var value 12
Current Thread Thread -1 var value 13
Current Thread Thread -2 var value 13
Current Thread Thread -1 var value 14
Current Thread Thread -2 var value 14
Current Thread Thread -3 var value 15
Current Thread Thread -3 var value 16
Current Thread Thread -3 var value 17
Current Thread Thread -3 var value 18