锁的常见概念
- 互斥: 同一时刻只有一个线程执行
- 临界区:一段需要互斥执行的代码
- 细粒度锁: 用不同的锁对受保护资源进行精细化管理。 细粒度锁可以提高并行度,是性能优化的一个重要手段
- 死锁 ：一组互相竞争资源的线程因互相等待，导致“永久”阻塞的现象 。
用锁的最佳实践
- 永远只再更新对象的成员变量时加锁。
- 永远只在访问可变的成员变量时加锁。
- 永远不再调用其它对象的方法时加锁。
- 减少所得持有时间，减小锁的粒度。
同步与异步
- 调用方法如果需要等待结果，就是同步；如果不需要等待结果就是异步。
- 同步是Java代码默认的处理方式。
如何实现程序支持异步：
- 异步调用： 调用方创建一个子线程，再子线程中执行方法调用。
- 异步方法： 被调用方；方法实现的时候，创建一个显得线程执行主要逻辑，主线程直接return。
synchronized
class X{
//修饰非静态方法
synchronized void foo(){
//临界区
}
//修饰静态方法
synchronized static void bar(){
//临界区
}
//修饰代码块
Object obj = new Object();
void baz(){
synchronized(obj){
//临界区
}
}
}
Java编译器会在synchronized修饰的方法或代码块前后自动加上加锁lock()和解锁unlock()，这样做的好处就是加锁lock()和解锁unlock()一定 是成对出现的，毕竟忘记解锁unlock()可是个致命的Bug（意味着其他线程只能死等下去了）。
修饰静态方法:
//修饰静态方法是用当前类的字节码文件作为锁
class X{
//修饰静态方法
synchronized(X.class) static void bar(){
//临界区
}
}
修饰非静态方法:
//修饰非静态方法是用当前对象作为锁
class X{
//修饰非静态方法
synchronized(this) static void bar(){
//临界区
}
}
如何用一把锁保护多个资源
受保护资源和锁之间合理的关联关系应该是N:1的关系，也就是说可以用一把锁来保护多个资源，但是不能用多把锁来保护一个资源，
使用锁的正确姿势
依转账业务作为示例
示例一：
public class Account {
/**
*锁：保护账⼾余额
*/
private final Object balLock = new Object();
/**
* 账⼾余额
*/
private Integer balance;
/**
* 错误的做法
* 非静态方法的锁是this,
* this这把锁可以保护自己的余额this.balance，保护不了别人的余额 target.balance
*
*/
synchronized void transfer(Account target,int amt){
if (this.balance > amt) {
this.balance -= amt;
target.balance += amt;//这段代码会出现线程安全,要保证线程安全的话要使用同一个锁
}
}
}
示例二：
public class Account {
/**
*锁：保护账⼾余额
*/
private final Object balLock = new Object();
/**
* 账⼾余额
*/
private Integer balance;
/**
* 正确的做法，但是会导致整个转账系统的串行
*
* Account.class是所有Account对象共享的，
* 而且这个对象是Java虚拟机在加载Account类的时候创建的，
* 所以我们不用担心它的唯一性
*
* 这样还有个弊端:所有的转账都是串行了
*/
void transfer2(Account target,int amt){
synchronized(Account.class){
if (this.balance > amt) {
this.balance -= amt;
target.balance += amt;
}
}
}
}
这样的话转账操作就成了串行的了，正常的逻辑应该只锁转入账号和被转入账户；不影响其他的转账操作。稍作改造:
示例三：
public class Account {
/**
*锁：保护账⼾余额
*/
private final Object lock;
/**
* 账⼾余额
*/
private Integer balance;
//私有化无参构造
private Account(){}
//设置一个传递lock的有参构造
private Account(Object lock){
this.lock = lock;
}
/**
* 转账
*/
void transfer(Account target,int amt){
//此处检查所有对象共享锁
synchronized(lock){
if (this.balance > amt) {
this.balance -= amt;
target.balance += amt;
}
}
}
}
这个方法虽然能够解决问题,但是它要求创建Account对象的时候必须传入同一个对象,
还有就是传递对象过于麻烦,写法繁琐缺乏可行性。
示例四：
public class Account {
/**
* 账⼾余额
*/
private Integer balance;
/**
* 转账
*/
void transfer(Account target,int amt){
//此处检查所有对象共享锁
synchronized(Account.class){
if (this.balance > amt) {
this.balance -= amt;
target.balance += amt;
}
}
}
}
用Account.class作为共享的锁,锁定的范围太大。 Account.class是所有Account对象共享的，而且这个对象是Java虚拟机在加载Account类的时候创建的，所以我们不用担心它的唯一性。使用Account.class作为共享的锁，我们就无需在创建Account对象时传入了。
这样新的问题就出来了虽然用Account.class作为互斥锁，来解决银行业务里面的转账问题，虽然这个方案不存在 并发问题，但是所有账户的转账操作都是串行的，例如账户A转账户B、账户C转账户D这两个转账操作现实 世界里是可以并行的，但是在这个方案里却被串行化了，这样的话，性能太差。所以如果考虑并发量这种方法也不行的
正确的写法是这样的(使用细粒度锁):
示例五：
public class Account {
/**
* 账⼾余额
*/
private Integer balance;
/**
* 转账
*/
void transfer(Account target,int amt){
//锁定转出账户
synchronized(this){
//锁住转入账户
synchronized(target){
if (this.balance > amt) {
this.balance -= amt;
target.balance += amt;
}
}
}
}
}
细粒度锁有可能会出现死锁
- 死锁 ：一组互相竞争资源的线程因互相等待，导致“永久”阻塞的现象 。
- 两个线程彼此拿着对方的资源都不释放就会导致死锁,
- 使用细粒度锁可能会导致死锁
如何避免死锁
- 互斥,共享资源X和Y只能被一个线程占用;
- 占有且等待,线程T1已经取得共享资源X,在等待共享资源Y的时候,不释放共享资源x;
- 不可抢占,其他线程不能强行抢占线程T1占有的资源;
- 循环等待,线程1等待线程T2占有的资源,线程T2等待线程T1占有的资源,就是循环等待。
只要破坏其中一个就可以避免死锁
等待-通知机制
用synchronized实现等待-通知机制
wait与sleep区别:
sleep是Object的中的方法,wait是Thread中的方法
wait会释放锁,sleep不会释放锁
wait需要用notif唤醒,sleep设置时间,时间到了唤醒
wait无需捕获异常,而sleep需要
wait(): 当前线程进入阻塞
**** 码字不易如果对你有帮助请给个关注****
**** 爱技术爱生活 QQ群: 894109590****