多线程，锁与ConcurrentHashMap

多线程，锁与ConcurrentHashMap

多线程

概念

• 多线程是为了同步完成多项任务，不是为了提高运行效率，而是为了提高资源使用效率
  来提高系统的效率。线程是在同一时间需要完成多项任务的时候实现的。
• 相当于玩游戏机，只有一个游戏机（cpu），可是有很多人要玩，于是，start是排队！等CPU选中你就是轮到你，你就run（），当CPU的运行的时间片执行完，这个线程就继续排队，等待下一次的run（）。

start

• .start（）方法来启动线程，真正实现了多线程运行

  • 通过调用Thread类的start()方法来启动一个线程，这时此线程是处于就绪状态，并没有运行。
  • 然后通过此Thread类调用方法run()来完成其运行操作的，这里方法run()称为线
    程体，它包含了要执行的这个线程的内容，Run方法运行结束，此线程终止，而CPU再
    运行其它线程，

run

• 注意：run()只是在当前线程中执行任务，而start才是真正生成thread，并放在cpu中调度。

wait和sleep

• wait
• sleep

锁

可重入锁（Re entran tLock）

• 可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，在进入内层方法会自动获取锁

• 可实现 代码同步,需要手动释放锁。

• 对于Java ，Synchronized而言,也是一个可重入锁。可重入锁的一个好处是可一定程度避免死锁。

• AQS

  • 是除了java自带的synchronized关键字之外的锁机制。
  • AQS就是基于CLH队列，用volatile修饰共享变量state，线程通过CAS去改变状态符，成功则获取锁成功，失败则进入等待队列，等待被唤醒
  • AQS是自旋锁：**在等待唤醒的时候，经常会使用自旋（while(!cas())）的方式，不停
    地尝试获取锁，直到被其他线程获取成功
  • 实现了AQS的锁有：自旋锁、互斥锁、读锁写锁、条件产量、信号量、栅栏都是AQS的衍生物

独享锁/共享锁

• 独享锁是指该锁一次只能被一个线程所持有。

  • 对于ReentrantLock而言，其就是独享所

• 共享锁是指该锁可被多个线程所持有。

  • ReadWriteLock：读是共享锁，写是独享所

    • 读锁的共享锁可保证并发读是非常高效的，读写，写读 ，写写的过程是互斥的。

  • Semaphore、CountDownLatch、CyclicBarrier

  • 独享锁与共享锁也是通过AQS（AbstractQueuedSynchronizer 抽象的队列式的同步器）来实现的，通过实现不同的方法，来实现独享或者共享

互斥锁mutex

• Mutex是一个不可重入的互斥锁实现。锁资源（AQS里 的state）只有两种状态：0表示未锁定，1表示锁定

  • 互斥锁在Java中的具体实现就是ReentrantLock

• 读写锁ReadWriteLock

乐观锁/悲观锁

• 悲观锁认为对于同一个数据的并发操作，一定是会发生修改的，哪怕没有修改，也会认为修改。因此对于同一个数据的并发操作，悲观锁采取加锁的形式。悲观的认为，不加锁的并发操作一定会出问题。

  • 悲观锁适合写操作非常多的场景
  • 悲观锁在Java中的使用，就是利用各种锁
  • 排他锁

• 乐观锁则认为对于同一个数据的并发操作，是不会发生修改的。在更新数据的时候，会采用尝试更新，不断重新的方式更新数据。乐观的认为，不加锁的并发操作是没有事情的。

  • 乐观锁适合读操作非常多的场景，共享锁

  • 乐观锁在Java中的使用，是无锁编程，常常采用的是CAS算法，典型的例子就是原子类，通过CAS自旋实现原子操作的更新。

    • CAS(Compare And Swap)j是一种无锁算法，在不使用锁（没有线程被阻塞）的情况下，实现多线程之间的变量同步。

      • 优势 效率高 劣势 浪费算力资源

    • CAS有3个操作数，内存值V，旧的预期值A，要修改的新值B，当且仅
      当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做。

    • AAb问题

      • CPU去更新一个值，但如果想改的值不再是原来的值，操作就失败，因为很明显，有其它操作先改变了这个值。
      • 就是指当两者进行比较时，如果相等，则证明共享数据没有被修改，替换成新值，然后
        继续往下运行；如果不相等，说明共享数据已经被修改，放弃已经所做的操作，然后重
        新执行刚才的操作。容易看出 CAS 操作是基于共享数据不会被修改的假设，采用了类
        似于数据库的commit-retry 的模式。当同步冲突出现的机会很少时，这种假设能带来
        较大的性能提升

ConcurrentHashMap

采用了CAS + synchronized来保证并发安全性,支持多线程并发

快速失败和安全失败

快速失败

• 在用迭代器遍历一个集合对象时，如果遍历过程中对集合对象的内容进行了修改（增加、删除、修改），则会抛出 Concurrent Modification Exception。原理：迭代器在遍历时直接访问集合中的内容，并且在遍历过程中使用一个modCount 变量。集合在被遍历期间如果内容发生变化，就会改变 modCount 的值。每当迭代器使用 hashNext()/next() 遍历下一个元素之前，都会检测 modCount 变量是否为 expectedmodCount 值，是的话就返回遍历；否则抛出异常，终止遍历。注意：这里异常的抛出条件是检测到 modCount != expectedmodCount 这个条件。如果集合发生变化时修改 modCount 值刚好又设置为了 expectedmodCount 值，则异常不会抛出。因此，不能依赖于这个异常是否抛出而进行并发操作的编程，这个异常只建议用于检测并发修改的 bug。场景：java.util 包下的集合类都是快速失败的，不能在多线程下发生并发修改（迭代过程中被修改）。

安全失败

• 采用安全失败机制的集合容器，在遍历时不是直接在集合内容上访问的，而是先复制原有集合内容，在拷贝的集合上进行遍历。原理：由于迭代时是对原集合的拷贝进行遍历，所以在遍历过程中对原集合所作的修改并不能被迭代器检测到，所以不会触发 Concurrent Modification Exception。 >缺点：基于拷贝内容的优点是避免了 Concurrent Modification Exception，但同样地，迭代器并不能访问到修改后的内容，即：迭代器遍历的是开始遍历那一刻拿到的集合拷贝，在遍历期间原集合发生的修改迭代器是不知道的。场景：java.util.concurrent 包下的容器都是安全失败，可以在多线程下并发使用，并发修改。