1.线程同步机制
并发:同一个对象被多个线程同时操作。
- 现实生活中,我们会遇到“同一个资源,多个人都想使用"的问题,比如,食堂排队打饭,每个人都想吃饭,最天然的解决方法就是排队,一个一个来。
- 处理多线程问题时,多个线程访问同一个对象,并且某些线程还想修改这个对象,这时就需要线程同步,线程同步其实就是一种等待机制,多个需要同时访问此对象的线程进入这个对象的等待池形成队列,等待前面线程使用完毕,下一个线程再使用。
由于同一进程的多个线程共享同一块存储空间,在带来方便的同时,也带来了访问冲突问题,为了保证数据在方法中被访问时的正确性,在访问时加入锁机制synchronized,当一个线程获得对象的排它锁,独占资源,其他线程必须等待,使用后释放锁即可,存在以下问题:
1.一个线程持有锁会导致其他所有需要此锁的线程挂起;
2.在多线程竞争下,加锁和释放锁会导致比较多的上下文切换和调度延时,引起性能问题。
3.如果一个优先级高的线程等待一个优先级低的线程释放锁,会导致优先级倒置,引起性能问题。
2.同步方法
1.由于我们可以通过private关键字来保证数据对象只能被方法访问,所以我们只需要针对方法提出一套机制,这套机制就是synchronized关键字,它包括两种用法:synchronized方法和synchronized块。
同步方法:public synchronized void method(int args){}
2.synchronized方法控制对“对象”的访问,每个对象对应一把锁,每个synchronized方法都必须获得调用该方法的对象的锁才能执行,否则线程会阻塞,方法一旦执行,就独占该锁,直到该方法返回才释放锁,后面被阻塞的线程才能获得这个锁,继续执行。
缺陷:若将一个大的方法声明为synchronized将会影响效率。
3.同步块
1.同步块:synchronized(obj){}
2.obj称之为同步监视器
- obj可以是任意对象,但是推荐使用共享资源作为同步监视器
- 同步方法中无需指定同步监视器,因为同步方法的同步监视器就是this,就是这个对象本身,或者是class
3.同步监视器的执行过程
- 第一个线程访问,锁定同步监视器,执行其中代码。
- 第二个线程访问,发现同步监视器被锁定,无法访问。
- 第一个线程访问完毕,解锁同步监视器。
- 第二个线程访问,发现同步监视器没有锁,然后锁定并访问。
4.死锁
多个线程各自占有一些共享资源,并且互相等待其他线程占有的资源才能运行,而导致两个或多个线程都在等待对方释放资源,都停止执行的情形。某一个同步块同时拥有“两个以上对象锁”时,就可能发生死锁的问题。
死锁避免方法
产生死锁的四个条件:
1.互斥条件:一个资源每次只能被一个进程使用。
2.请求与保持条件:一个进程因请求资源二阻塞时,对以获得的资源保持不放。
3.不剥夺条件:进程以获得的资源,在未使用完之前,不能强行剥夺。
4.循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
任意破坏其中一个条件就可以避免死锁。
5.Lock(锁)
- 从JDK5.0开始,Java提供了更强大的线程同步机制–通过显式定义同步锁对象来实现同步。同步锁使用Lock对象充当。
- java.util.concurrent.locks.Lock接口是控制多个线程对共享资源进行访问的工具。锁提供了对共享资源的独占访问,每次只能有一个线程对Lock对象加锁,线程开始访问共享对象资源之前按应先获得Lock对象
- ReentrantLock类实现了Lock,它拥有与synchronized相同的并发性和内存语义,在实现线程安全的控制中,比较常用的时ReentrantLock,可以显式加锁,释放锁。
举例:加锁可以保证代码的安全
class A{
private final ReentrantLock lock = new ReentrantLock();
public void m(){
lock.lock();
try {
//保证安全的代码
}
finally {
lock.unlock();
//如果同步代码有异常,要将unlock()写入finally语句中
}
}
}
synchronized与lock的对比
- Lock是显式锁(手动开启和关闭锁,别忘记关闭锁),而synchronized是隐式锁,出了作用域自动释放。
- Lock只有代码块锁,synchronized有代码块锁和方法锁。
- 使用Lock锁,JVM将花费较少的时间来调度线程,性能更好,并且具有更好的扩展性(提供更多的子类)
- 优先使用顺序:
Lock > 同步代码块(已经进入了方法体,分配了相应资源) > 同步方法(在方法体之外)