如果可能的话，让你的数据不可变(最终变量) 如果你不能避免跨多个线程共享数据的突变，使用高级编程结构[例如，粒度锁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包。

我将分别讨论每一点。

Some evil code may steal your lock (very popular this one, also has an "accidentally" variant) I'm more worried about accidentally. What it amounts to is that this use of this is part of your class' exposed interface, and should be documented. Sometimes the ability of other code to use your lock is desired. This is true of things like Collections.synchronizedMap (see the javadoc). All synchronized methods within the same class use the exact same lock, which reduces throughput This is overly simplistic thinking; just getting rid of synchronized(this) won't solve the problem. Proper synchronization for throughput will take more thought. You are (unnecessarily) exposing too much information This is a variant of #1. Use of synchronized(this) is part of your interface. If you don't want/need this exposed, don't do it.

避免使用synchronized(this)作为锁定机制:这会锁定整个类实例，并可能导致死锁。在这种情况下，重构代码以只锁定特定的方法或变量，这样整个类就不会被锁定。同步可以在方法级别内使用。 下面的代码展示了如何锁定一个方法，而不是使用synchronized(this)。

   public void foo() {
if(operation = null) {
    synchronized(foo) { 
if (operation == null) {
 // enter your code that this method has to handle...
          }
        }
      }
    }

这要视情况而定。 如果只有一个或多个共享实体。

在这里查看完整的工作示例

简单介绍一下。

线程和可共享实体 多个线程可以访问同一个实体，例如多个connectionThreads共享一个messageQueue。由于线程并发运行，可能会有一个数据被另一个覆盖的机会，这可能是一个混乱的情况。 因此，我们需要某种方法来确保可共享实体一次只能被一个线程访问。(并发)。

同步块 Synchronized()块是一种确保可共享实体并发访问的方法。 首先，打个小比方 假设有两个人P1, P2(线程)一个盥洗室(可共享实体)，有一扇门(锁)。 现在我们想让一个人一次使用脸盆。 一种方法是在P1锁门的时候P2等待P1完成他的工作 P1打开门 那么只有p1可以使用脸盆。

语法。

synchronized(this)
{
  SHARED_ENTITY.....
}

"this" provided the intrinsic lock associated with the class (Java developer designed Object class in such a way that each object can work as monitor). Above approach works fine when there are only one shared entity and multiple threads (1: N). N shareable entities-M threads Now think of a situation when there is two washbasin inside a washroom and only one door. If we are using the previous approach, only p1 can use one washbasin at a time while p2 will wait outside. It is wastage of resource as no one is using B2 (washbasin). A wiser approach would be to create a smaller room inside washroom and provide them one door per washbasin. In this way, P1 can access B1 and P2 can access B2 and vice-versa.

washbasin1;  
washbasin2;

Object lock1=new Object();
Object lock2=new Object();

  synchronized(lock1)
  {
    washbasin1;
  }

  synchronized(lock2)
  {
    washbasin2;
  }

在这里查看更多关于Threads---->的信息

虽然我同意不要盲目地遵守教条规则，但“偷锁”的场景对你来说是不是很古怪?一个线程确实可以从你的对象“外部”获得锁(synchronized(theObject){…})，阻塞其他线程等待同步实例方法。

如果您不相信恶意代码，请考虑这些代码可能来自第三方(例如，如果您开发了某种应用程序服务器)。

“意外”版本似乎不太可能，但就像他们说的那样，“让一些东西不受白痴的影响，就会有人发明一个更好的白痴”。

所以我同意“这取决于这个班级做什么”的观点。

编辑以下eljenso的前3条评论:

我从来没有遇到过偷锁的问题，但这里有一个想象的场景:

假设您的系统是一个servlet容器，我们考虑的对象是ServletContext实现。它的getAttribute方法必须是线程安全的，因为上下文属性是共享数据;所以你声明它是同步的。让我们再想象一下，您提供了一个基于容器实现的公共托管服务。

我是您的客户，并在您的站点上部署我的“好”servlet。我的代码碰巧包含对getAttribute的调用。

黑客伪装成另一个客户，在您的站点上部署恶意servlet。它在init方法中包含以下代码:

synchronized (this.getServletConfig().getServletContext()) {
   while (true) {}
}

假设我们共享相同的servlet上下文(只要两个servlet位于同一个虚拟主机上，规范就允许)，那么我对getAttribute的调用将永远锁定。黑客已经在我的servlet上实现了DoS。

如果getAttribute在私有锁上同步，则这种攻击是不可能的，因为第三方代码无法获得此锁。

我承认这个例子是人为设计的，对servlet容器如何工作的看法过于简单，但恕我直言，它证明了这一点。

因此，我将基于安全性考虑做出设计选择:我是否能够完全控制访问实例的代码?线程无限期地持有实例锁的后果是什么?

锁可以用于可见性，也可以用于保护一些数据不受可能导致竞争的并发修改的影响。

当您需要将基本类型操作设置为原子类型时，可以使用AtomicInteger之类的选项。

但是假设你有两个整数，它们像x和y坐标一样彼此相关，它们彼此相关，应该以原子的方式改变。然后使用相同的锁来保护它们。

锁应该只保护彼此相关的状态。不多不少。如果在每个方法中都使用synchronized(this)，那么即使类的状态是不相关的，即使更新不相关的状态，所有线程也将面临争用。

class Point{
   private int x;
   private int y;

   public Point(int x, int y){
       this.x = x;
       this.y = y;
   }

   //mutating methods should be guarded by same lock
   public synchronized void changeCoordinates(int x, int y){
       this.x = x;
       this.y = y;
   }
}

在上面的例子中，我只有一个方法同时改变x和y，而不是两个不同的方法，因为x和y是相关的，如果我给了两个不同的方法分别改变x和y，那么它就不会是线程安全的。

这个例子只是为了演示它的实现方式，而不一定是这样。最好的方法是让它成为IMMUTABLE。

现在，与Point例子相反的是，@Andreas已经提供了一个TwoCounters的例子，其中状态被两个不同的锁保护，因为状态彼此不相关。

使用不同的锁来保护不相关的状态的过程称为锁剥离或锁分裂