Java并发编程与高并发笔记
ExecutorService 线程池
CountDownLatch 线程阻塞
Semaphore 信号量
线程安全性
何种调度方式，不需要任何额外的同步或协同，都能表现出正确的行为
原子性、
AtomicInteger：一个死循环内不断的修改目标值，直到修改成功；竞争不激烈修改成功率很高，否则修改失败率很高
jvm把Long、Double读操作和写操作拆成两个32位的操作
AtomicLong： 依靠底层的cas来保障原子性的更新数据，在要添加或者减少的时候，会使用死循环不断地cas到特定的值，从而达到更新数据的目的
LongAdder：在AtomicLong的基础上将单点的更新压力分散到各个节点，在低并发的时候通过对base的直接更新可以很好的保障和AtomicLong的性能基本保持一致，而在高并发的时候通过分散提高了性能。
缺点是LongAdder在统计的时候如果有并发更新，可能导致统计的数据有误差。
可见性、
导致共享变量在线程间不可见的原因
线程交叉执行
重排序结合线程交叉执行
共享变量更新后的值没有在工作内存与主存间及时更新
有序性
原则
线程终结规则
对象终结规则
原子性-锁
synchronized：依赖JVM
修饰代码块：大括号括起来的代码，作用于调用的对象
修饰方法：整个方法，作用于调用的对象
修饰静态方法：整个静态方法，作用于所有的对象
修饰类：括号括起来的部分，作用于所有对象
Lock：依赖特殊的CPU指令，代码实现，ReentrantLock
原子性-比对
synchronized：不可中断锁，适合竞争不激烈，可读性好
Lock：可中断锁，多样化同步，竞争激烈时能维持常态
Atomic：竞争激烈时能维持常态，比Lock性能好；只能同步一个值
不可变
final、Collections.unmodifiableMap、ImmutableList、ImmutableSet、ImmutableMap
线程封闭
Ad-hoc线程封闭：程序控制实现，最糟糕，忽略
堆栈封闭：局部变量，无并发问题
ThreadLocal线程封闭：特别好的封闭方法
线程不安全类
StringBuilder-->StringBuffer(线程安全)
SimpleDateFormat-->DateTimeFormatter(线程安全)
ArrayList、HashSet、HashMap、Hashtable(线程安全)
线程安全-同步容器
ArrayList-->Vector、Stack
HashMap-->Hashtable(key/value不能为null)
Collections.synchronizedXXX(List、Set、Map)
线程安全--并发容器J.U.C
ArrayList->CopyOnWriteArrayList
HashSet、TreeSet->CopyOnWriteArraySet、ConcurrentSkipListSet
HashMap、TreeMap->ConcurrentHashMap、ConcurrentSkipListMap
线程限制：一个被线程限制的对象，由线程独占，并且只能被占有它的线程修改
共享只读：一个共享只读的对象，在没有额外同步的情况下，可以被多个线程并发访问，但是如何线程都不能修改它
线程安全对象：一个线程安全的对象或者容器，在内部通过同步机制来保证线程安全，所以其他线程无需额外的同步就可以通过公共接口随意访问它
被守护对象：被守护对象只能通过获取特定的锁来访问
AQS同步组件
CountDownLatch：闭锁，通过一个计数来保证线程是否需要堵塞
Semaphore：控制同一时间并发线程的数目[备注：if (semaphore.tryAcquire(5000, TimeUnit.MILLISECONDS)) {//等待5秒内，尝试获取一个许可]
CyclicBarrier：跟Semaphore相似
ReentrantLock：
synchronized是基于JVM层面实现的，而Lock是基于JDK层面实现的
对于使用者的直观体验上Lock是比较复杂的，需要lock和realse，如果忘记释放锁就会产生死锁的问题，所以，通常需要在finally中进行锁的释放。但是synchronized的使用十分简单，只需要对自己的方法或者关注的同步对象或类使用synchronized关键字即可。但是对于锁的粒度控制比较粗，同时对于实现一些锁的状态的转移比较困难
ReentrantLock支持两种锁模式，公平锁和非公平锁。默认的实现是非公平的
写操作必须在没有读锁存在的时候，才能进行写同步操作
线程数量少量synchronized，线程数量不断增加，不可估量ReentrantLock
Condition：Condition的使用方式是比较简单的，需要注意的是使用Condition的等待/通知需要提前获取到与Condition对象关联的锁，Condition对象由Lock对象创建
使用场景：线程A执行到某个点的时候，因为某个条件condition不满足，需要线程A暂停；等到线程B修改了条件condition，使condition满足了线程A的要求时，A再继续执行。
FutureTask：在使用java实现异步时最常用到的一个类，我们可以向线程池提交一个Callable，并通过future对象获取执行结果
Fork/Join框架：用于并行执行任务的框架，是一个把大任务分割成若干个小任务，最终汇总每个小任务结果后得到大任务结果的框架
BlockingQueue：
ArrayBlockingQueue：初始化的时候指定大小，指定了就不能再变，先进先出，最先插入的数据在尾部，移除的数据在头部
DelayQueue：使用场景定时关闭连接，超时处理
LinkedBlockingQueue：配置可选，初始化时指定了大小是有边界的，不指定大小就是无边界的
PriorityBlockingQueue：有更新级的阻塞队列，没有边界的队列
SynchronousQueue：内部只能容纳一个元素，当插入一个元素后，队列就会被阻塞，无界非缓存的队列
线程池
new Thread弊端
每次new Thread新建对象，性能差
线程缺乏统一管理，可能无限制的新建线程，相互竞争，有可能占用过多系统资源导致死机或OOM
缺少更多功能，如更多执行、定期执行、线程中断
线程池的好处
重用存在的线程，减少对象创建、消亡的开销，性能佳
可有效控制最大并发线程数，提高系统资源利用率，同时可以避免过多资源竞争，避免阻塞
提供定时执行、定期执行、单线程、并发数控制等功能
线程池-ThreadPooIExecutor
corePooISize：核心线程数量
maximumPooISize：线程最大线程数
workQueue：阻塞队列，存储等待执行的任务，很重要，会对线程池运行过程产生重大影响
keepAliveTime：线程没有任务执行时最多保持多久时间终止
unit：keepAliveTime的时间单位
threadFactory：线程工厂，用来创建线程
rejectHandler：当拒绝处理任务时的策略
execute()：提交任务，交给线程池执行
submit()：提交任务，能够放回执行结果execute+Future
shutdown()：关闭线程池，等待任务都执行完
shutdownNow()：关闭线程池，不等待任务执行完
getTaskCount()：线程池已执行和未执行的任务总数
getCompletedTaskCount()：已完成的任务数量
getPooISize()：线程池当前的线程数量
getActiveCount()：当前线程池中正在执行的线程数量
线程池-Executor框架接口
Executors.newCachedThreadPool：可缓存的线程池，如果线程池数量超过数据需要，没有可回收线程，则新建线程
Executors.newFixedThredPool：创建定长的线程池，可控制线程的最大并发数，超过的线程会在等待
Executors.newScheduledThreadPool：创建定长的线程池，支持定时，周期性任务执行
Executors.newSingleThreadExecutor：创建单线程化的线程池，只会用唯一的线程来执行任务，先进先出，优先级处理
线程池-合理配置
CPU密集型任务，就需要尽量压榨CPU，参考值可以设为NCPU+1
IO密集型任务，参考值可以设置为2*NCPU
死锁-必要条件
互斥条件：锁对进程所分配的排它性使用，在一段时间内，某资源只能由一个资源在使用，其他资源在请求资源，只能等待
请求和保持条件：进程至少保持着一个资源，但又提出了新的资源请求，而该资源已在被其他资源占用，此时请求进程阻塞，但又以自己和其他进程保持着不放
不剥夺条件：进程已获得资源在未使用完前不能被剥夺，在使用完时自己释放
环路等待条件：
多线程并发最佳实践
使用本地变量
使用不可变类
最小化锁的作用域范围：S=1/(1-a+a/n)
使用线程池的Executor，而不是直接new Thread执行
宁可使用同步也不要使用线程的wait和notify
使用BlockingQueue实现生产-消费模式
使用并发集合而不是加了锁的同步集合
使用Semaphore创建有界的访问
宁可使用同步代码块，也不使用同步的方法
避免使用静态变量
HashMap：采用了链地址法，也就是数组+链表的方式
高并发解决方案
扩容
垂直扩容（纵向扩展）：提高系统部件能力
水平扩容（横向扩展）：增加更多系统成员来实现
扩容-数据库
读操作扩展：memcache、redis、CDN等缓存
写操作扩展：Cassandra、Hbase等
缓存特征
命中率：命中数/(命中数+没有命中数)
最大元素（空间）
清空策略：FIFO（先进先出），LFU（最小使用策略），LRU，过期时间，随机等
缓存命中率影响因素
业务场景和业务需求
缓存的设计（粒度和策略）
缓存容量和基础设施
缓存分类和应用场景
本地缓存：编程实现（成员变量、局部变量、静态变量）、Guava Cache
分布式缓存：Memcache、Redis
消息队列
Kafka：快速持久化，高吞吐
RabbitMQ
应用拆分-原则
业务优先
循序渐进
兼顾技术：重构、分层
可靠测试
应用限流
计数器法、滑动窗口、漏桶算法、令牌桶算法
服务降级与服务熔断
服务降级、服务熔断
共性：目的。最终表现、粒度、自治
区别：触发原因、管理目标层次、实现方式
服务降级分类
自动降级：超时、失败次数、故障、限流
人工降级：秒杀、双11大促等
服务降级要考虑的问题
核心服务、非核心服务
是否支持降级，降级策略
业务放通场景，策略
Hystrix
在通过第三方客户端访问（通常是通过网络）依赖服务出现高延迟或者失败时，为系统提供保护和控制
在分布式系统中防止级联失败
快速失败（Fail fast）同时能快速恢复
提供失败回退（Fallback）和优雅的服务降级机制
数据库切库、分库、分表
数据库瓶颈：
单个库数据量太大（1T~2T）：分库
单个数据库服务器压力过大、读写瓶颈：多个库
单个表数据量过大：分表
数据库切库
切库的基础及实际运用：读写分类
自定义注解完成数据库切库-代码实现
数据库支持多个数据源与分库
支持多数据源、分库
数据库分表
什么时候考虑分表
横向（水平）分表与纵向（垂直）分表
数据库分表：mybatis分表插件shardbatis2.0
高可用的一些手段
任务调度系统分布式：elastic-job+zookeeper
主备切换：apache curator+zookeeper分布式锁实现
监控报警机制
