如果可能的话，让你的数据不可变(最终变量) 如果你不能避免跨多个线程共享数据的突变，使用高级编程结构[例如，粒度锁API]

Lock提供对共享资源的独占访问:一次只有一个线程可以获得锁，并且对共享资源的所有访问都要求首先获得锁。

使用ReentrantLock实现Lock接口的示例代码

 class X {
   private final ReentrantLock lock = new ReentrantLock();
   // ...

   public void m() {
     lock.lock();  // block until condition holds
     try {
       // ... method body
     } finally {
       lock.unlock()
     }
   }
 }

锁定相对于同步的优势

The use of synchronized methods or statements forces all lock acquisition and release to occur in a block-structured way. Lock implementations provide additional functionality over the use of synchronized methods and statements by providing A non-blocking attempt to acquire a lock (tryLock()) An attempt to acquire the lock that can be interrupted (lockInterruptibly()) An attempt to acquire the lock that can timeout (tryLock(long, TimeUnit)). A Lock class can also provide behavior and semantics that is quite different from that of the implicit monitor lock, such as guaranteed ordering non-re entrant usage Deadlock detection

看看这个关于各种锁的SE问题:

同步vs锁定

您可以通过使用高级并发API而不是synchronized块来实现线程安全。该文档页提供了实现线程安全的良好编程结构。

锁对象支持简化许多并发应用程序的锁定习惯用法。

executor为启动和管理线程定义了高级API。concurrent提供的执行器实现提供了适合大型应用程序的线程池管理。

并发集合使管理大型数据集合变得更容易，并且可以大大减少同步的需要。

原子变量具有最小化同步和帮助避免内存一致性错误的特性。

ThreadLocalRandom(在JDK 7中)提供了从多个线程有效生成伪随机数的功能。

其他编程结构也可以参考java.util.concurrent和java.util.concurrent.atomic包。

这取决于你想做的任务，但我不会用它。此外，检查您想要完成的线程保存是否不能首先通过同步(此)来完成?API中也有一些不错的锁，可能会帮助到你:)

我认为第一点(其他人使用您的锁)和第二点(所有方法不必要地使用相同的锁)可能发生在任何相当大的应用程序中。特别是当开发人员之间没有良好的沟通时。

这不是一成不变的，这主要是一个良好的实践和防止错误的问题。

不进行同步的原因是，有时您需要多个锁(经过一些额外的思考后，第二个锁通常会被删除，但您仍然需要它处于中间状态)。如果你锁定了这个，你总是要记住两个锁中哪个是这个;如果你锁定一个私有对象，变量名会告诉你。

从读者的角度来看，如果你看到了锁定，你总是必须回答两个问题:

这能保护什么样的权限? 一把锁真的够了吗，难道不是有人引入了漏洞吗?

一个例子:

class BadObject {
    private Something mStuff;
    synchronized setStuff(Something stuff) {
        mStuff = stuff;
    }
    synchronized getStuff(Something stuff) {
        return mStuff;
    }
    private MyListener myListener = new MyListener() {
        public void onMyEvent(...) {
            setStuff(...);
        }
    }
    synchronized void longOperation(MyListener l) {
        ...
        l.onMyEvent(...);
        ...
    }
}

如果两个线程在BadObject的两个不同实例上开始longOperation()，它们将获得 他们的锁;当调用l.onMyEvent(…)时，会出现死锁，因为两个线程都不能获得其他对象的锁。

在本例中，我们可以通过使用两个锁来消除死锁，一个用于短操作，一个用于长操作。

这实际上只是对其他答案的补充，但如果你对使用私有对象进行锁定的主要反对意见是，它会使你的类与与业务逻辑无关的字段混乱，那么Project Lombok有@Synchronized在编译时生成样板:

@Synchronized
public int foo() {
    return 0;
}

编译,

private final Object $lock = new Object[0];

public int foo() {
    synchronized($lock) {
        return 0;
    }
}

在c#和Java阵营中似乎有不同的共识。我看到的大多数Java代码使用:

// apply mutex to this instance
synchronized(this) {
    // do work here
}

而大多数c#代码选择了更安全的:

// instance level lock object
private readonly object _syncObj = new object();

...

// apply mutex to private instance level field (a System.Object usually)
lock(_syncObj)
{
    // do work here
}

c#语言当然更安全。如前所述，不能从实例外部对锁进行恶意/意外访问。Java代码也有这种风险，但随着时间的推移，Java社区似乎倾向于稍微不那么安全，但稍微更简洁的版本。

这并不是对Java的挖苦，只是我在这两种语言上工作的经验的反映。