JAVA多线程(3)

JAVA多线程(3)

锁分类

是否锁同步资源(乐观锁、悲观锁)

• 乐观锁：一种乐观思想，即认为读多写少，遇到并发写的可能性低，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，采取在写时先读出当前版本号，然后加锁操作（比较跟上一次的版本号，如果一样则更新），如果失败则要重复读-比较-写的操作。
• java 中的乐观锁基本都是通过 CAS 操作实现的，CAS 是一种更新的原子操作，比较当前值跟传入值是否一样，一样则更新，否则失败。
• 悲观锁：一种悲观思想，即认为写多，遇到并发写的可能性高，每次去拿数据的时候都认为别人会修改，所以每次在读写数据的时候都会上锁，这样别人想读写这个数据就会 block 直到拿到锁。java中的悲观锁就是synchronized；

线程是否阻塞(自旋锁)

• 如果持有锁的线程能在很短时间内释放锁资源，那么那些等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞挂起状态，它们只需要等一等（自旋），等持有锁的线程释放锁后即可立即获取锁，这样就避免用户线程和内核的切换的消耗。
• 线程自旋是需要消耗 CPU 的，说白了就是让 CPU在做无用功，如果一直获取不到锁，那线程也不能一直占用CPU自旋做无用功，所以需要设定一个自旋等待的最大时间。如果持有锁的线程执行的时间超过自旋等待的最大时间扔没有释放锁，就会导致其它争用锁的线程在最大等待时间内还是获取不到锁，这时争用线程会停止自旋进入阻塞状态。
• 自旋锁的优点：
  • 自旋锁尽可能的减少线程的阻塞，这对于锁的竞争不激烈，且占用锁时间非常短的代码块来说性能能大幅度的提升，因为自旋的消耗会小于线程阻塞挂起再唤醒的操作的消耗，这些操作会导致线程发生两次上下文切换！

线程竞争时是否排队(公平锁、非公平锁)

• 公平锁：锁的分配机制是公平的，加锁前检查是否有排队等待的线程，优先排队等待的线程，先来先得
• 非公平锁：加锁时不考虑排队等待问题，JVM 按随机、就近原则分配锁的机制则称为不公平锁，非公平锁实际执行的效率要远远超出公平锁（5-10倍），除非程序有特殊需要，否则最常用非公平锁的分配机制。

线程中的多个流程是否可以获取同一把锁(可重入锁(递归锁))

可重入锁，也叫做递归锁，指的是同一线程外层函数获得锁之后 ，内层递归函数仍然有获取该锁的代码，但不受影响。在 JAVA 环境下 ReentrantLock 和 synchronized 都是可重入锁。

多线程之间能不能共享同一把锁(共享锁和排他锁)

• 共享锁：共享锁则允许多个线程同时获取锁，并发访问 共享资源，如：ReadWriteLock。共享锁则是一种乐观锁，它放宽了加锁策略，允许多个执行读操作的线程同时访问共享资源。
• 排他锁：每次只能有一个线程能持有锁，ReentrantLock 就是以独占方式实现的互斥锁。独占锁是一种悲观保守的加锁策略，它避免了读/读冲突，如果某个只读线程获取锁，则其他读线程都只能等待，这种情况下就限制了不必要的并发性，因为读操作并不会影响数据的一致性。

锁的状态

• 锁的状态总共有四种：无锁状态、偏向锁、轻量级锁和重量级锁。
• 锁升级：随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁（但是锁的升级是单向的，
  也就是说只能从低到高升级，不会出现锁的降级）。
• 无锁没有对资源进行锁定，所有的线程都能访问并修改同一个资源，但同时只有一个线程能修改成功。
• 偏向锁是指一段同步代码一直被一个线程所访问，那么该线程会自动获取锁，降低获取锁的代价。在大多数情况下，锁总是由同一线程多次获得，不存在多线程竞争，所以出现了偏向锁。其目标就是在只有一个线程执行同步代码块时能够提高性能
• 轻量级锁：当锁是偏向锁的时候，被另外的线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，从而提高性能。
• 重量级锁：升级为重量级锁时，锁标志的状态值变为“10”，此时Mark Word中存储的是指向重量级锁的指针，此时等待锁的线程都会进入阻塞状态。
• 死锁:
  • 两个或两个以上的线程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法让程序进行下去！
  • 如何查看线程死锁：通过jstack命令进行查看，jstack中会显示发生死锁的线程
• 数据库中查看死锁：
  • 查看是否有表锁：show OPEN TABLES where In_use > 0；
  • 查询进程：show processlist;
  • 查看正在锁的事务：SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
  • 查看等待锁的事务：SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS_WAITS;