synchronized修饰实例方法锁的是当前对象实例（this），修饰静态方法锁的是当前类的Class对象；二者互不干扰，可同时执行。
Java中synchronized修饰实例方法时锁的是什么
锁的是当前对象实例（
），每个对象有自己的监视器（monitor）。不同对象调用同一synchronized实例方法，互不阻塞。
常见错误现象：以为加了synchronized就全局串行，结果多个对象并行执行，数据仍出错——因为你没意识到锁粒度是对象级的。
适用场景：保护对象内部状态，比如银行账户的
方法
注意：
等价于
如果方法内访问的是静态字段，它并不能保证线程安全——静态字段属于类，不是实例
synchronized修饰静态方法或代码块时锁的是什么
锁的是当前类的
对象，即
。所有线程调用该类的任意synchronized静态方法，都会竞争同一把锁。
典型误用：在静态工具类里用synchronized实例方法保护共享缓存，结果无效——因为每次new出来的对象锁不同，根本没拦住并发。
立即学习
“
Java免费学习笔记（深入）
”；
静态同步方法等价于
类锁和对象锁互不干扰：一个线程持有某对象的实例锁，另一个线程仍可进入该类的静态同步方法
类锁本质是JVM为每个类维护的一个全局
实例，不可被new出来，也不受GC影响
怎么验证对象锁和类锁是否真的互斥
写两个线程：一个调用synchronized实例方法，另一个调用synchronized静态方法，观察是否能同时进入——可以，说明它们用的是两把不同的锁。
Eclipse导入Android或其他的JAVA项目的正确方法 WORD版
本文档主要讲述的是Eclipse导入Android或其他的JAVA项目的正确方法；希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
下载
示例关键片段：
运行后会看到两行输出几乎同时打印，证明未阻塞。
想让它们互斥？只能手动统一用同一把锁，比如都用
JDK 1.6之后，偏向锁、轻量级锁等优化可能掩盖争抢现象，测试建议关闭偏向锁：
面试常踩的坑：锁升级、volatile和ReentrantLock混淆
对象锁不是固定不变的。JVM会根据竞争情况将锁从“无锁→偏向锁→轻量级锁→重量级锁”升级，但**不会降级**。面试问“锁升级过程”，重点不是背阶段，而是理解它为何存在：减少CAS自旋开销。
不提供原子性，不能替代synchronized——它只保证可见性和禁止重排序，对
这种复合操作完全无效
是显式锁，支持公平性、中断响应、条件队列，但必须配对
，且
要放在finally里
别迷信“synchronized慢”：JDK 1.8后性能已接近ReentrantLock，除非需要其高级特性，否则优先用synchronized——更简洁、不易出错
真正容易被忽略的是锁的范围与生命周期：锁对象本身要是稳定不变的；若锁对象被重新赋值（比如
），旧锁就失效了，新对象又是一把新锁。
thiswithdraw()synchronized void method()void method() { synchronized(this) { ... } }ClassMyClass.classsynchronized(MyClass.class) { ... }Classpublic class LockDemo {
public synchronized void instanceMethod() {
System.out.println("进入实例方法，锁：" + this);
try { Thread.sleep(2000); } catch (InterruptedException e) {}
}
public static synchronized void staticMethod() {
System.out.println("进入静态方法，锁：" + LockDemo.class);
try { Thread.sleep(2000); } catch (InterruptedException e) {}
}
}synchronized(LockDemo.class)-XX:-UseBiasedLockingvolatilei++ReentrantLocklock()/unlock()unlock()obj = new Obj()