JSR-133 FAQ表示：
但是同步不仅仅意味着互斥。同步确保线程在同步块之前或期间写入的内存对于在同一监视器上同步的其他线程以可预测的方式可见。在我们退出同步块后，我们会释放监视器，这会刷新缓存到主内存中，使得该线程进行的写入可以对其他线程可见。在进入同步块之前，我们需要获取监视器，这会使本地处理器缓存失效，以便从主内存重新加载变量。然后，我们就能看到前一个发布所公开的所有写入。
我还记得在现代Sun VM中，无争用锁同步是低成本的。但是这种说法让我有点困惑。考虑以下代码：
class Foo {
int x = 1;
int y = 1;
..
synchronized (aLock) {
x = x + 1;
}
}
对x的更新需要同步，但是锁的获取是否也会从缓存中清除y的值？我无法想象这种情况存在，因为如果是真的，那么像锁分离这样的技术可能就没有帮助了。另外，JVM可否可靠地分析代码，以确保在使用相同锁的另一个同步块中不修改y，从而在进入同步块时不将y的值转储到缓存中？
class Foo {
int x = 1;
int y = 1;
..
void bar() {
synchronized (aLock) {
x = x + 1;
}
y = y + 1;
}
}
bar看到的y的值不应该比获取锁时的“真实”值旧。这意味着缓存必须使y和x都无效。
此外，JVM能否可靠地分析代码，以确保使用相同锁定的另一个同步块中没有修改
y？
如果锁定对象是this，那么一旦所有类都被预加载，这种分析似乎就可以作为全局优化来完成。（我并不是说这很容易或值得做...）
在更一般的情况下，证明给定的锁仅与给定的“所有”实例连接使用的问题可能是棘手的。
同步保证了只有一个线程可以进入代码块。但它并不能保证在同步块内进行的变量修改对其他线程可见。只有进入同步块的线程才能保证看到这些更改。 在Java中，同步的内存效果可以与C++和Java相关的双重检查锁问题进行比较。 双重检查锁被广泛引用和用作在多线程环境下实现延迟初始化的有效方法。不幸的是，在Java中实现时无法以平台独立的方式可靠地工作，需要额外的同步。在其他语言（如C++）中实现时，它取决于处理器的内存模型、编译器执行的重新排序以及编译器和同步库之间的交互。由于这些都没有在像C++这样的语言中指定，因此很难说它会在哪些情况下起作用。可以使用显式内存屏障来使其在C++中工作，但在Java中不存在这些屏障。