使用“锁”时遇到的坑

没有分析清线程、业务逻辑和锁三者之间的关系随意添加无效的方法锁

上述代码在理想情况下，应该是不会产生任何输出（a和b相等），但实际上有概率打印出日志。

错误的解决方案

给add()添加锁，但实际上无法解决。

之所以出现这种错乱，是因为两个线程是交错执行 add 和 compare 方法的， 而且这两个方法的业务逻辑不是原子性的，即a++ 和 b++ 操作中可以穿插在 compare 方法的比较代码中；更需要注意的是，a<b 这种比较操作在字节码层面是加载 a、加载 b和比较三步， 代码虽然是一行但也不是原子性的。

正确的解决方案

所以，正确的做法应该是，为 add 和 compare 都加上方法锁，确保 add 方法执行时，compare 无法读取 a 和 b。

加锁前要清楚锁和被保护的对象是不是一个层面的

上述代码中，在类Data中定义了一个静态的int字段counter和一个非静
态的wrong方法，实现counter字段的累加操作。

若使用多线程循环调用累加操作100万次，理想情况下counter的值应该是100万，但实际上会是一个错误的值。

在非静态的 wrong 方法上加锁，只能确保多个线程无法执行同一个实例的 wrong 方法，却不能保证不会执行不同实例的 wrong 方法（所以多线程场景下就会出现问题）。而静态的 counter 在多个实例中共享，所以必然会出现线程安全问题。

解决方案

定义一个静态的对象作为锁，累加时上锁（锁的是类，所以保证该类的静态变量的安全）。