






















修饰普通方法A时 锁住的是调用该方法的实例对象 也就是this对象 其有一把锁和一个等待队列 获取锁失败的线程进入等待队列。
同一个类的普通方法B也用synchronized修饰的话 那么它锁住的也是this对象 因此不仅不同线程调用A方法或B方法时需要同步执行 同时调用A和B方法也需要同步执行。
如果该类里面有没被synchronized修饰的普通方法也访问了共享变量 那么同样该共享变量也是线程不安全的 要限制只能synchronized修饰的方法访问该共享变量。
修饰静态方法时 锁住的是该类的class对象 其同样有一把锁和一个等待队列。
用synchronized修饰方法的话 临界区太大了 方法里很多不需要考虑线程安全的的代码也被限制了 可以用synchronized锁代码块 只锁需要线程安全的代码 更精细也更高效。
synchronized修饰后 同一类的普通方法 锁定都是this 静态方法锁定的是都是.class 如果不想彼此影响 可以分别定义锁对象来控制。
共享数据在方法区或者堆那里 当线程执行代码用到时将其加载到自己的函数栈去使用 如果之后共享数据的修改该线程不知道 那么就会出现错误。
要避免这种情况 需要做到两点 一方面线程修改了数据后及时将修改同步到共享数据 另一方面线程使用该值时去共享数据处获取最新值而不是使用缓存 这样修改就对所有线程可见了。可以用synchronized实现 但volatile更轻量 成本更小。
从Collections里获取到的同步容器 其实只是对所有方法都加synchronized来修饰 这样所有操作都是线程安全的。
但容器操作的复合操作却不是线程安全的 比如常见业务操作 取值计算后再设置回去 单独取值和单取设置值都是线程安全的 但整个流程却不是线程安全 因为get之后会释放锁 在set之前可能有其他线程来获取锁操作完又释放锁了。用synchronized来修改整个方法也没用 因为其锁定的是当前实例对象 而get和set却是用容器对象控制 所以用synchronized(容器对象)控制代码块 在代码块里进行get和set 这样才是线程安全的。
在对容器迭代时 如果容器元素发生修改修改 会抛出ConcurrentModificationException异常。而同步容器没有解决这个问题 它单个操作是线程安全的 但迭代不是。因此对同步容器迭代时 需要用用synchronized(容器对象)先锁住 然后在代码块里进行迭代 。迭代过程中 想修改元素需要获取容器对象锁而不得。
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。