HashMap的扩容机制原理
1.7版本
- 先生成新的数组
- 遍历老数组中的每个位置上的链表 它的每个元素
- 取出当前元素 基于新数组的长度 计算出每个元素对应的新数组下标的位置
- 将元素添加到新数组中
- 所有元素转移完之后 将新数组赋值给HashMap的Table对象
1.8版本
- 先生产新的数组
- 遍历老数组每个位置上的链表或红黑树
- 如果是链表 则直接将链表上的每个元素重新计算下标 并添加到新数组中
- 如果是红黑树 则先去遍历红黑树 计算红黑树对应新数组对应的下标位置
统计每个下标的元素个数
如果红黑树元素超过8 则生成一个新的红黑树 并将根节点添加新数组对应位置
如果红黑树元素没有超过8 则生成一个链表 并将链表头节点添加到新数组对应位置
5.所有元素转移完之后 并将新数组赋值给HashMap的Table对象
线程池的状态
六种状态及转换
- 新建
- 当一个线程对象被创建，但还未调用 start 方法时处于新建状态
- 此时未与操作系统底层线程关联
- 可运行
- 调用了 start 方法，就会由新建进入可运行
- 此时与底层线程关联，由操作系统调度执行
- 终结
- 线程内代码已经执行完毕，由可运行进入终结
- 此时会取消与底层线程关联
- 阻塞
- 当获取锁失败后，由可运行进入 Monitor 的阻塞队列阻塞，此时不占用 cpu 时间
- 当持锁线程释放锁时，会按照一定规则唤醒阻塞队列中的阻塞线程，唤醒后的线程进入可运行状态
- 等待
- 当获取锁成功后，但由于条件不满足，调用了 wait() 方法，此时从可运行状态释放锁进入 Monitor 等待集合等待，同样不占用 cpu 时间
- 当其它持锁线程调用 notify() 或 notifyAll() 方法，会按照一定规则唤醒等待集合中的等待线程，恢复为可运行状态
- 有时限等待
- 当获取锁成功后，但由于条件不满足，调用了 wait(long) 方法，此时从可运行状态释放锁进入 Monitor 等待集合进行有时限等待，同样不占用 cpu 时间
- 当其它持锁线程调用 notify() 或 notifyAll() 方法，会按照一定规则唤醒等待集合中的有时限等待线程，恢复为可运行状态，并重新去竞争锁
- 如果等待超时，也会从有时限等待状态恢复为可运行状态，并重新去竞争锁
- 还有一种情况是调用 sleep(long) 方法也会从可运行状态进入有时限等待状态，但与 Monitor 无关，不需要主动唤醒，超时时间到自然恢复为可运行状态
其它情况（只需了解）
- 可以用 interrupt() 方法打断等待、有时限等待的线程，让它们恢复为可运行状态
- park，unpark 等方法也可以让线程等待和唤醒
线程池参数
要求
- 掌握线程池的 7 大核心参数
七大参数
- corePoolSize 核心线程数目 - 池中会保留的最多线程数
- maximumPoolSize 最大线程数目 - 核心线程 救急线程的最大数目
- keepAliveTime 生存时间 - 救急线程的生存时间，生存时间内没有新任务，此线程资源会释放
- unit 时间单位 - 救急线程的生存时间单位，如秒、毫秒等
- workQueue - 当没有空闲核心线程时，新来任务会加入到此队列排队，队列满会创建救急线程执行任务
- threadFactory 线程工厂 - 可以定制线程对象的创建，例如设置线程名字、是否是守护线程等
- handler 拒绝策略 - 当所有线程都在繁忙，workQueue 也放满时，会触发拒绝策略
- 抛异常 java.util.concurrent.ThreadPoolExecutor.AbortPolicy
- 由调用者执行任务 java.util.concurrent.ThreadPoolExecutor.CallerRunsPolicy
- 丢弃任务 java.util.concurrent.ThreadPoolExecutor.DiscardPolicy
- 丢弃最早排队任务 java.util.concurrent.ThreadPoolExecutor.DiscardOldestPolicy
