Java工程师面试脑图思维导图模板_ProcessOn思维导图、流程图

LinuxOS

Linux常用命令

Shell脚本编程

中间软件

Redis

使用场景

4+X

注意事项

缓存雪崩

大量可以在同一时间失效

Redis集群宕机

缓存穿透

缓存击穿

热点key问题

缓存和数据库双写一致性问题

用作分布式锁的缺陷问题

丢数据问题

主从复制

脑裂

技术选型

数据结构

集群

持久化

内存使用率

效率

线程模型

常用数据结构

常用数据结构及其使用场景

常用数据结构及其实现内幕

String

OBJ_ENCODING_INT

OBJ_ENCODING_EMBSTR

OBJ_ENCODING_RAW

Hash

OBJ_ENCODING_ZIPLIST

OBJ_ENCODING_HT

扩容

数组第一纬的长度（触发扩容，但是bgsave进行时不触发）

数组第一纬长度的5倍（强制触发扩容）

缩容

不足数组第一纬大小的10%

渐进式rehash

两个触发条件

List

OBJ_ENCODING_QUICKLIST

Set

OBJ_ENCODING_INTSET

OBJ_ENCODING_HT

ZSet

OBJ_ENCODING_ZIPLIST

OBJ_ENCODING_SKIPLIST + OBJ_ENCODING_HT

底层数据结构

8个字节的长整型

long

SDS

embstr

raw

ziplist

quicklist

dict

intset

skiplist

内存模型（RedisObject）

RedisServer

RedisDb

dict

dictht

dictEntry

key

value

线程模型

那个图

缓存过期策略

惰性删除

定期删除

缓存淘汰机制

缓存淘汰算法

数据持久化机制

rdb

aof

aof重写流程

那个图

主从复制原理

全量复制

部分复制

异步复制

集群原理

slot

RocketMQ

使用场景

注意事项

技术选型（RabbitMQ、RocketMQ、KAFKA）

开发语言

社区活跃度

基本功能

都支持

扩展功能

顺序消息

都支持

延时消息

都支持

事务消息

只有RocketMQ支持事务消息

消息回溯

KAFKA支持

RocketMQ支持

RabbitMQ不支持

消息查询

只有RocketMQ支持消息查询

高性能

单请求耗时

单机吞吐量

高可用

可伸缩

RabbitMQ完败

MQ原理

那个图

MQ实现

基本功能

消息发送

同步

CountdownLatch

异步

SendCallback

消息存储

数据库存储

并发问题

单机10w级别 = 50个

文件存储

commitlog

消息

consumequeue

正常topic队列

延时topic队列

消费组重试队列

死信队列

config

消息消费offset

index

消息查询

过期文件删除机制

定时任务没隔10分钟检查过期文件

过期文件删除

默认每天四点

存储空间剩余不足10%

手动执行删除命令

消息消费

订阅消息

TopicA

%RETRY%ConsumerGroupX

扩展功能

顺序消息

指定发送的哪个Broker+哪个ConsumerQueue

普通消息轮询Broker+ConsumerQueue发送

消费失败了咋办？

延时消息

SCHEDULE_TOPIC_XX

延时级别

事务消息

消息回溯

消息查询

架构设计

高性能

写：顺序写 + page cache（页缓存） + mmap（0 内核空间缓存区和用户空间缓缓冲区之间的拷贝）

读：基于Netty，0 CPU 拷贝 -> sendfile(Linux 2.6.23 之后)

单条消息大于4k压缩传输

批量传输

KAFKA常用

RocketMQ一般不用

高可用

集群协调高可用

服务端高可用

消息存储

同步刷盘

主从复制

同步复制

消息全链路可靠传输

生产者异步+回调

服务端同步复制+同步刷盘

消费者手动ACK

可伸缩

加机器就可以扩容

加机器就可以提高吞吐量

NameServer

分布式集群协调（类似ZK，又比ZK简单）

Broker管理

发现

移除

Routing管理

常见问题

消息积压的处理方案

MQ集群宕机的简单备用方案

Redis

异地多活根本解决

Zookeeper

使用场景

命名服务

注册中心

配置中心

分布式锁

分布式队列

分布式协调

集群HA

注意事项

脑裂

为什么旧的leader重新连回来之后不根据epoch判断将自己改为Follower

羊群效应

工作原理

从Paxos到ZAB

ZAB协议

广播模式

恢复模式

Leader选举机制

epoch

zxid

sid

节点角色

Leader

Learner

Follower

Observer

节点状态

Leading

Following

Observing

全局事务

zxid

高低位

副本机制

读写流程

$7.8

持久机制

事务日志

数据快照

多少次记录事务日志后dump快照

系统模型

数据模型

znode

树形结构

节点类型

监听机制

exists

getData

getChildren

线程模型

典型的Reactor主从模型

性能分析

16核32G：单机几万QPS

每个节点都可以读

适合小集群部署

半数机制

写请求无法扩展

适合读多写少的场景

Observer节点扩展

ElasticSearch

倒排索引

term

b,c,a

term dictionary

a,b,c

term index

trie树

posting list

docId集合

每个字段对应一个倒排索引

写入时，refresh（每秒）过程就会创建索引

集群原理

集群组建

数据分片几副本

读写流程

故障恢复

集群扩容

分片数量

副本数量

副本复制原理

读写原理

写

读

查询

搜索

性能优化

利用操作系统缓存（1：1）

索引只存必要的字段（ES+MySQL或HBase）

数据预热

冷热分离

避免复杂的关联查询

设计合理的Document模型（mapping）

分页优化

性能优化

web前端性能优化

终端优化

传输优化

反向代理

动静分离

CDN加速

应用服务性能优化

集群

缓存

异步

代码

并发编程

资源复用

数据结构

分析工具

Arthas

Btrace

Byteman

JVM

数据存取性能优化

SQL优化

索引优化

数据库架构+分库分表

架构技能

分布式架构

Keepalive+Nginx/LVS

Zookeeper

RPC

Dubbo

SpringCloud

服务治理

服务熔断

服务降级

服务限流

服务隔离

MQ

RocketMQ

KAFKA

缓存

Redis

Memcached

分布式数据一致性

微服务架构

Docker

数据库架构

主备架构

主从架构

双主架构

架构的要素

高性能

高可用

可扩展

可伸缩

安全性

BigData

数据收集

网络爬虫

Flume/Logstash/Beats

Flume+KAFKA+ELK

数据存储

HDFS

Hive

Hbase

MongoDB

数据检索

Elasticsearch

数据处理

MapReduce

Hive

Storm

Spark

Flink

数据挖掘

机器学习

解决方案

技术解决方案

业务解决方案

其他技能

开发工具

Intellij IDEA

Eclipse

项目构建

Maven

Gradle

版本控制

Git

SVN

专业基石

数据结构

4+1+2+1+3=11

算法

算法思想

分治算法

贪心算法

回溯算法

动态规划

常用算法

3+1+X

LRU&LFU

Snowflake

限流算法

负载均衡算法

一致性Hash算法

TopK算法

Java基础

基础

反射

注解

Stream

ThreadLocal

使用场景

线程隔离资源

无法解决共享资源的更新

线程生命周期内，可以在任意地方获取使用

用户登录后存一个token到ThreadLocal，之后哪里用到哪里获取

数据结构

thread.threadLocals

ThreadLocal.ThreadLocalMap

Entry extends WeakReference<ThreadLocal<?>>

Entry[]

常用算法

set

threadLocalMap.set

get

threadLocalMap.getEntry

remove

threadLocalMap.remove

initialValue

默认是返回null

可以在创建ThreadLocal时传入一个initialValue的实现

这是一个延迟调用方法，在未set先get时调用

重要的点

早期版本和8之后的版本对比

如果用的是线程池+静态的Class生命周期的ThreadLocal，那么真没多大区别

真要强说区别，就是1.7及之前，如果线程很多，ThreadLocal的ThreadLocalMap会很大

通常ThreadLocal没有线程多

nextHashCode()

ThreadLocalMap

注意事项

用完remove

集合

List

ArrayList

Vector

CopyOnWriteArrayList

CopyOnWriteArraySet

LinkedList

SynchronizedList

Collections.synchronizedList(list)

Map

HashMap

内部结构

Node

TreeNode extends LinkedHashMap.Entry extends HashMap.Node

Node[] + Node链表或TreeNode红黑树

常用方法

put

get

remove

size

重要的点

hash函数

hash值高16位和低16位异或

为什么要这么设计

hash冲突

ThreadLocalHashMap

防止复杂度退化 -> 红黑树（>=8&>=64）

扩容策略

优化死循环

hash&oldCap

注意事项

合理设置初始容量

线程安全问题

HashTable

ConcurrentHashMap

HashTable

ConcurrentHashMap

数据结构

Node

ForwardingNode extends Node（MOVED=-1）

扩容时，大用处

TreeBin extends Node（TREEBIN=-2）

有料，控制读写并发问题

waiter：Thread

lockState：int

WRITER（1）

WAITER（2）

READER（4）

TreeNode extends Node

ReservationNode extends Node（RESERVED=-3）

Node[] + Node链表或TreeNode红黑树

volatile int sizeCtl

0

-1

-N

正数

常用算法

put

get

remove

size&mappingCount

sumCount

重要的点

线程安全

写写（put）

table为空，自旋+cas初始化

Node[x]为null（bin的头节点为null），自旋+cas插入

Node[x]为ForwardingNode，帮助扩容

其他情况（Node[x]为Node或TreeBin时），synchronized锁

读写

链表时，没问题

红黑树时，有问题

扩容策略

sizeCtl

transferIndex

多线程扩容时，按stride分配bin给线程

transferIndex=oldTab.length; transferIndex-= stride;

helpTransfer

transfer

1. 空结点或迁移完的桶（bin）的头结点上插入forward节点

2. 桶（bin）搬移的时候，将 bin 的头结点锁住

3. 最后一个扩容线程会负责重新检查一遍数组查看是否有遗漏的桶

判断最后一个扩容线程就是看sizeCtl是否等于启动扩容时设置的基数（(rs << RESIZE_STAMP_SHIFT) + 2）

4. 扩容结束后，将 table 指向新数组，sizeCtl 设置为扩容阈值

负载因子默认0.75f不可通过构造方法设置

容量计数（baseCount&counterCells）

类似LongAdder

为什么要用LongAdder而不用AtomicLong

注意事项

合理设置初始容量

LinkedHashMap

数据结构

LinkedHashMap.Entry extends HashMap.Node

Entry[] + Entry链表或红黑树

head&tail

常用算法

put

newNode -> linkNodeLast -> 将新节点添加到链表尾节点

afterNodeInsertion -> removeEldestEntry -> 若达到容量，则将头节点删除

afterNodeAccess(需要构造方法传入accessOrder=true) -> 把被访问的节点调到尾部

get -> afterNodeAccess(需要构造方法传入accessOrder=true)-> 把被访问的节点调到尾部

remove -> afterNodeRemoval -> 将删除的节点从链表中移除（由于结构设计的好，只要改变前后指针即可）

注意事项

排序不是常规的按照某种方式排序，只是把最近使用的放到队尾

ThreadLocalMap

数据结构

Entry extends WeakReference<ThreadLocal<?>>

Entry[]

常用算法

set

replaceStaleEntry

找到key为null的Entry，将新的Entry放到这个位置

清理过去数据

cleanSomeSlots

expungeStaleEntry

清理过期数据

碰到正常数据，重新计算索引位置

getEntry

getEntryAfterMiss

expungeStaleEntry

remove

expungeStaleEntry

重要的点

hash算法

private final int threadLocalHashCode = nextHashCode();

每个ThreadLocal对象只有一个hash值，创建ThreadLocal对象时就定了

nextHashCode() -> return nextHashCode.getAndAdd(HASH_INCREMENT);

初始为0（nextHashCode）

静态方法，每调用一次（new ThreadLocal()）就在原来值（nextHashCode）的基础上加上一个Fibonaci数作为新的hash值

Fibonaci数是一个跟Fibonaci数列有关的黄金分割数，就为了散列更均匀（最大程度散列到一个2的n次方的数组里）

hash冲突

线性探测法（开放寻址法的一种）

这种方式不适合数据量大的情况

扩容策略

扩容前会先进行过期数据的清理

没有桶，就是数组扩容

注意事项

size不宜太大

hash冲突解决办法决定 + 常用方法决定

TreeMap

红黑树

key没有hash

key不能重复

Set

HashSet

TreeSet

CopyOnWriteArraySet

就是在插入数据时，先遍历一下数组快照，看是否存在，其他就是调用CopyOnWriteArrayList相关方法（addIfAbsent）

Stack

使用场景

先进后出

数据结构

数组

Stack extends Vector

常用方法

push(E)

pop()

注意事项

数据量不要很大

线程安全，但是效率不高

Queue

ArrayBlockingQueue

LinkedBlockingQueue

PriorityBlockingQueue

ConcurrentLinkedQueue

volatile + cas + 自旋

适合并发不大的情况

SynchronousQueue

ArrayDeque

双端队列，非线程安全，只有顺序实现，没有链式实现

IO/NIO

BIO

阻塞（accept()、read()）-> 连接：线程=1：1 -> C10K问题

阻塞唤醒：硬中断或软中断

NIO

非阻塞（accept()、read()）+ 自旋（多个连接可以用一个线程） -> 海量syscall -> 海量用户空间和内核空间切换和数据拷贝

零拷贝

多路复用IO

select

poll

epoll

信号驱动IO

AIO

网络编程

网络模型

TCP三次握手和四次挥手

为何需要三次握手

拆包粘包问题

http v.s. https

网络问题排查

并发编程

并发基石

JMM

MESI

MESI底层实现原理

内存屏障

cas

原子性

lock cmpxchgl %1,(%3)

ABA

底层cas是没有ABA问题，上层应用cas才有ABA问题

1、获取共享变量

2、修改共享变量

3、cas回写共享变量

compareAndSwap -> 调底层cas操作

volatile

可见性

JVM层面

底层层面

有序性

JVM层面

底层层面

synchronized

可见性

JVM层面

底层层面

有序性

JVM层面

底层层面

原子性

JVM层面

底层层面

JVM底层实现（monitorentry()，monitorexit()）

偏向锁

为什么要引入偏向锁

加锁流程

重入

解锁流程

重入

升级流程

撤销偏向锁为什么要等到safe point再执行

轻量级锁

为什么要引入轻量级锁

加锁流程

重入

解锁流程

重入

升级流程

重量级锁

可能触发升级重量级锁的情况

轻量级锁升级

wait()

hashCode()

objectMonitor（mutex结构体）

_owner

cas操作_owner

lock前缀指令

monitorentry -> lock cmpxchg %r15, 0x16(%r10)

monitorexit -> lock cmpxchg %r10, (%r11)

_recursions

三个队列

_cxq

_EntryList

_WaitSet

加锁流程

重入

解锁流程

重入

锁优化

偏向锁 -> 轻量级锁（自旋 -> 自适应自旋） -> 重量级锁

锁粗化 -> 连续获取同一把锁

锁消除 -> 对局部变量加锁

锁分段

锁分解

锁自动超时（lock）

可中断锁（lock）

synchronized对比ReentrantLock（3+3+1）

公平？

限时？

中断？

读写锁

更灵活

线程状态

Condition更灵活

一个Lock可以创建多个Condition

效率

偏向锁状态下

synchronized优于ReentrantLock

轻量级锁状态下

自旋次数

CAS操作

重量级锁状态下

基本没多大区别，套路都是一样的

线程基础

Java线程实现

用户线程和系统轻量级进程（或线程）1：1映射实现

线程状态

NEW

RUNNABLE

READY

RUNNING

WAITING

TIMED_WAITING

BLOCKED

TERMINATED

线程中断机制（一种协作机制）

Thread.currentThread().interrupt() -> 设置线程的中断状态为true

没有任何效果

NEW

TERMINATED

只会设置线程中断状态为true

RUNNABLE

BLOCKED

响应中断

WAITING

wait()

join()

LockSupport.park()

lock.lockInterruptibly()

TIMED_WAITING

sleep(time)

wait(time)

join(time)

LockSupport.parkNanos(time)

lock.tryLock(time)

LockSupport.parkUtil(time)

Thread.currentThread().isInterrupted() -> 仅仅返回线程的中断状态

Thread.interrupted() -> 返回线程的中断状态并将中断状态设置为false

多线程

线程池

如何设置线程池的大小

计算密集型

n+1

IO密集型

那个公式

线程池原理

线程池状态（ctl：高3位-线程池状态，低29位-线程池有效线程数）

RUNNING（-1）

SHUTDOWN（0）

STOP（1）

各种参数

corePoolSize

maximumPoolSize

keepAliveTime+timeUnit

workQueue

threadFactory

handler

先后顺序

corePoolSize > workQueue > maximumPoolSize > handler

线程池实现

ThreadPoolExcutor

内部结构

ctl：AtomicInteger

workQueue：BlockingQueue<Runnable>

workers：HashSet<Worker>

Worker

thread

Worker继承了AQS，执行任务前加锁，完事解锁

这个锁感觉就是为了表示Worker在工作

启动流程

addWorker

new Worker(..).thread.start()：thread是线程工厂创建的Thread传入的Runnable是Worker

worker.run()：Worker也是Runnable

worker.runWorker()：步入正轨

getTask()：。。

allowCoreThreadTimeOut

常用方法

execute(..)

addWorker(..)

remove(..)

reject(..)

shutdown() -> SHUTDOWN

advanceRunState(SHUTDOWN)

停止接收新的任务

interruptIdleWorkers()

遍历workers，并interrupt空闲的线程（w.tryLock()成功才中断）

idle的工作线程会在getTask方法中等待从workQueue中获取任务，如果此时线程接到interrupt会响应中断，进而线程退出

processWorkerExit(..)

tryTerminate()

工作中的线程则会继续工作，直到工作队列空了，再响应中断，退出线程

tryTerminate()

工作线程空了，队列空了，紧接着清理，然后终止

SHUTDOWN -> TIDYING -> TERMINATED

shutdownNow()：List<Runnable> -> STOP

advanceRunState(STOP)

停止接收新的任务

interruptWorkers()

遍历workers，并interrupt

tasks = drainQueue()

将等待执行的任务出队，保存到tasks，并返给调用方

这一步就能保证，后续把interrupt的线程给退出

tryTerminate()

工作线程空了，队列空了，紧接着清理，然后终止

STOP -> TIDYING -> TERMINATED

prestartCoreThread()

预先启动一个核心线程

prestartAllCoreThreads()

预先启动所有核心线程

allowCoreThreadTimeOut(..)

allowCoreThreadTimeOut

允许核心线程超时退出

ScheduledThreadPoolExecutor

内部结构

ScheduledFutureTask

负责包装任务和任务执行后从新加入到任务队列（延时、周期）

DelayedWorkQueue

堆

无界，可以扩容

take()

poll(long timeout, TimeUnit unit)

常用方法

schedule(..)

scheduleAtFixedRate(..)

scheduleWithFixedDelay(..)

几个点吧

Leader/Follower模式

Leader定时挂起

Follower逐个唤醒

Timer与ScheduledThreadPoolExecutor的比较

绝对时间，相对时间

单线程，多线程

异常处理

ScheduledThreadPoolExecutor对比ThreadPoolExecutor

先创建Worker还是先入队列

很好理解，延时

ScheduledThreadPoolExecutor正常情况下maximumPoolSize没用，除非corePoolSize为0，此时会创建一个线程来执行，脑残才会这么用

线程池使用心得

自定义线程池ExecutorService executor = new ThreadPoolExecutor(...)

用ExecutorService 是因为它既有submit也有execute方法

线程工厂生产有意义名称的线程

方便排错

注意线程池吞异常的问题

任务的run()自己抓住处理

这个好

重写ThreadPoolExecutor的afterExecute(..)方法

很少用

submit获取线程池执行结果的原理

构建FutureTask并返回

private Callable<V> callable;

若submit的是Runnable，则先适配成Callable，再设置callable属性，并可以指定返回值，默认返回null

若submit提交的是Callable，则直接设置callable属性

private Object outcome;

线程池问题分析与解决思路

使用无界队列带来的问题

使用无限线程带来的问题

有限队列，有限线程时，如何自定义拒绝策略

还是根据业务场景

扔到MQ

持久化到任务表

机器宕机如何防止队列中的任务丢失

适合有状态的任务

常见问题

sleep和wait的区别

4+1

wait会将锁升级为重量级锁，sleep不会

如何获取多线程的执行结果

并行线程把结果写到一个地方（Result），再去取，还可以结合CountdownLatch和ReentrantLock.Condition

Runnable + Future + Callabl = Futhertask

state：状态及流转

NEW（0）

COMPLETING（1）

NORMAL（2）

EXCEPTIONAL（3）

CANCELLED（4）

INTERRUPTING（5）

INTERRUPTED（6）

run()

set()：NEW -> COMPLETING -> NORMAL

finishCompletion

setException()：NEW -> COMPLETING -> EXCEPTIONAL

finishCompletion

cancel(boolean)

true：NEW -> INTERRUPTING -> INTERRUPTED

false：NEW -> CANCELLED

get()/get(time)

report(awaitDone：返回状态)：根据状态返回结果

当前线程是否中断？

state > COMPLETING？

state == COMPLETING？

入队挂起当前线程

WaitNode链表

入队出队：CAS头节点

原子类

LongAdder

使用场景

为什么不用AtomicLong而用LongAdder

数据结构

base&cells

Cell

value：long

cellsBusy

cas锁

创建cells并初始化一个cell

创建cell

扩容

常用算法

add(long x)

increment() -> add(1L)

decrement() -> add(-1L)

sum() -> base + sum（cells）

重要的点

热点数据拆分思想

线程hash值存在一个ThreadLocal（LongAdder#threadHashCode）中

初始是一个随机整数

并发冲突时，改变线程的hash值，从新索引cell

cells初始容量为2，每次扩容翻倍，直到大于cpu核数不再扩容

AtomicLong

LongAdder

AtomicLongArray

AtomicReference<E>

AtomicReferenceArray<E>

AtomicReferenceFieldUpdater

AtomicStampedReference<E>

解决ABA问题

一个二元组[E,Integer]

AQS（AbstractQueuedSynchronizer）

内部结构

state

独占模式下

=0：代表没有线程占用锁

>0：代表有线程占用锁，具体数值代表重入的次数，释放时需要一一减掉，确保回到0

共享模式下

<0：代表获取锁失败

=0：代表获取锁成功，但没有剩余可用资源

>0：代表获取锁成功，且有剩余资源

head

tail

Node

waitStatus

CANCELLED（1）

SIGNAL（-1）

CONDITION（-2）

PROPAGATE（-3）

Node SHARED = new Node()

新建Node时，赋值给nextWaiter

Node EXCLUSIVE = null

新建Node时，赋值给nextWaiter

nextWaiter

等待队列，单向链表

ConditionObject

firstWaiter：head

lastWaiter：tail

核心方法

实现方法

acquire

tryAcquire

acquireQueued

addWaiter

Node.EXCLUSIVE

尝试获取成功？setHead：继续

shouldParkAfterFailedAcquire

parkAndCheckInterrupt

挂起，只记录中断标记

cancelAcquire

被中断或者限时挂起到时间，取消

acquireInterruptibly

tryAcquire

doAcquireInterruptibly

addWaiter

Node.EXCLUSIVE

尝试获取成功？setHead：继续

shouldParkAfterFailedAcquire

parkAndCheckInterrupt

挂起，响应中断，抛异常

cancelAcquire

被中断或者限时挂起到时间，取消

tryAcquireNanos

tryAcquire

doAcquireNanos

addWaiter

Node.EXCLUSIVE

尝试获取成功？setHead：继续

shouldParkAfterFailedAcquire

parkAndCheckInterrupt

挂起，响应中断，抛异常

cancelAcquire

被中断或者限时挂起到时间，取消

release

tryRelease

unparkSuccessor

清理取消的节点，并唤起最头上，满足条件的线程

acquireShared

tryAcquireShared

doAcquireShared

addWaiter

Node.SHARED

尝试获取成功？setHeadAndPropagate：继续

shouldParkAfterFailedAcquire

parkAndCheckInterrupt

挂起，只记录中断标记

cancelAcquire

被中断或者限时挂起到时间，取消

acquireSharedInterruptibly

tryAcquireShared

doAcquireSharedInterruptibly

addWaiter

Node.SHARED

尝试获取成功？setHeadAndPropagate：继续

doReleaseShared

shouldParkAfterFailedAcquire

parkAndCheckInterrupt

挂起，响应中断，抛异常

cancelAcquire

被中断或者限时挂起到时间，取消

tryAcquireSharedNanos

tryAcquireShared

doAcquireSharedNanos

addWaiter

Node.SHARED

尝试获取成功？setHeadAndPropagate：继续

shouldParkAfterFailedAcquire

parkAndCheckInterrupt

挂起，响应中断，抛异常

cancelAcquire

被中断或者限时挂起到时间，取消

releaseShared

tryReleaseShared

doReleaseShared

unparkSuccessor

清理取消的节点，并唤起最头上，满足条件的线程

模版方法

tryAcquire

tryAcquireShared

tryRelease

tryReleaseShared

常用实现

Lock

ReentrantLock

内部结构

FairSync extends Sync extends AQS

NonfairSync extends Sync extends AQS

常用方法

lock

sync.lock

lockInterruptibly

acquireInterruptibly

tryLock

tryAcquire

tryLock(time)

tryAcquireNanos

unlock

release

ReentrantReadWriteLock

内部结构

ReadLock

lock

acquireShared

lockInterruptibly

acquireSharedInterruptibly

tryLock

tryReadLock

tryLock(time)

tryAcquireSharedNanos

unlock

releaseShared

WriteLock

lock

acquire

lockInterruptibly

acquireInterruptibly

tryLock

tryWriteLock

tryLock(time)

tryAcquireNanos

unlock

release

FairSync extends Sync extends AQS

NonfairSync extends Sync extends AQS

常用方法

writeLock

readLock

Semaphore

内部结构

FairSync extends Sync extends AQS

NonfairSync extends Sync extends AQS

常用方法

acquire

acquireSharedInterruptibly

acquireUninterruptibly

acquireShared

tryAcquire

tryAcquireShared

tryAcquire(time)

tryAcquireSharedNanos

release

releaseShared

CountDownLatch

内部结构

Sync extends AQS

tryAcquireShared

模版方法实现

tryReleaseShared

模版方法实现

常用方法

await

acquireSharedInterruptibly

await(time)

tryAcquireSharedNanos

countDown

releaseShared

并发编程思维模型

是否必须共享变量？

是否可以用final修饰？

是否可以线程封闭

ThreadLocal

是否可以volatile+cas自旋

原子类

ConcurrentLinkedQueue

是否可以使用基于AQS实现的各种安全组件

Lock

ReentrantLock

BlockingQueue（Lock）

CopyOnWriteArrayList（Lock）

ConcurrentHashMap（CAS+Lock）

ReentrantReadWriteLock

Semaphore

CountdownLatch

使用synchronized锁

JVM

编译器

.java --javac--> .class

类加载

类加载的过程

加载

通过类的全限定名，获取类的二进制字节流

解析类的二进制字节流所描述的静态数据结构为方法区中的运行时数据结构

在堆中创建一个java.lang.Class类型的对象来存储类的信息数据

验证

两个文件规范

一个程序语义

符号引用验证

准备

静态变量分配空间，并赋初值

初值，比如int的初值是0

解析

将常量池中的符号引用解析为直接引用：#xx -> 具体内存地址

初始化

<clinit>()

静态变量赋值

静态代码块执行

基于静态内部类实现单例

JVM保证子类的<clinit>()执行之前父类的<clinit>()已执行

JVM保证一个类的<clinit>()在多线程环境中能正确执行（加锁）

双亲委派机制

模型

Custom ClassLoader

Application ClassLoader

Extension ClassLoade

Bootstrap ClassLoader

Extension ClassLoade

Application ClassLoader

Custom ClassLoader

优点

避免同一个类的重复加载

安全考虑，java核心类库中定义的类，不会被随意替换加载

常见违反双亲委派模型的操作

SPI

JDBC（java.sql.Driver属于核心类库）

本来是由Bootstrap ClassLoader加载的但是，其具体实现是在第三方jar中，在classpath下，所以要想加载具体实现就得违反

热部署

类加载器

Bootstrap ClassLoader

%JAVA_HOME%\jre\lib\rt.jar

Extension ClassLoader

%JAVA_HOME%\jre\lib\ext\*.jar

Application ClassLoader

%ClassPath%\*

自定义类加载器（CustomClassLoader extends ClassLoader）

遵循双亲委派机制

构造方法：super()或super(parent)

加载方法：调用loadClass()方法

违反双亲委派机制

super(null) -> loadClass()

重写并暴露findClass()方法 -> findClass()

一个问题

判断Class对象是否相等，不仅要判断类的全限定名是否相同，还要判断是否是由同一个类加载器加载

运行时数据区

内存划分

线程共享

堆

方法区

线程隔离

PC寄存器

java方法：记录当前线程正在指向的字节码指令的内存地址

native方法：空（Undefined）

栈

栈帧（方法）

局部变量表

操作数栈

动态连接

类是用到加载的，比如：方法中new一个对象，就会有类的加载过程，其中的解析过程就是动态连接

方法出口

附加信息

本地方法栈

对象探秘

对象的创建过程（X x = new X();）

加载？

分配内存

指针碰撞

空闲列表

设置对象头

这一步完成之后，从虚拟机的视角来看，一个新的队形已经产生了

对象初始化

<init>()

执行构造方法

执行构造代码块

引用赋值给变量

对象的内存布局

对象头

MarkWord

类型指针

指向类元数据的指针

实例数据

对齐填充

对64位机器：8字节的整数倍或者64位的整数倍

对象的访问定位

句柄访问

reference -> 句柄（对象实例数据的执指针，对象类型数据的指针）

直接指针访问

reference -> 对象内存地址（对象实例数据，对象类型数据的指针）

垃圾收集器

各种引用

强引用

软引用

弱引用

虚引用

无法通过虚引用来取得一个对象的实例，为一个对象设置虚引用关联的唯一目的就是在这个对象被GC时收到一个系统通知

类回收条件

对象

类对象

ClassLoader

对象晋升原则

晋升年龄阈值

动态对象年龄

大对象

young gc时survivor放不下

GCRoot（三色标记算法）

静态变量

常量

局部变量

栈

本地方法栈

存在跨代引用的对象

和GC Root处于同一CardTable的对象

垃圾收集算法

复制算法

标记清除算法

标记整理算法

常用垃圾收集器

Parallel Scavenge + Parallel Old

内存划分

-Xmn512m

-XX:SurvivorRatio=8

-XX:+UseAdaptiveSizePolicy

垃圾收集算法

GC活动周期

常用参数

ParNew + CMS + Serial Old

内存划分

-Xmn512m

-XX:SurvivorRatio=8

垃圾收集算法

GC活动周期

常用参数

-XX:+UseConcMarkSweepGC

-XX:CMSInitiatingOccupancyFraction=80

-XX:+UseCMSInitiatingOccupancyOnly

-XX:UseCMSCompactAtFullCollection

-XX:CMSFullGCBeforeCompaction=5

-XX:+CMSPrecleaningEnabled

-XX:+CMSScavengeBeforeRemark

G1

内存划分

Region（-XX:G1HeapRegionSize）

E

S

O

H

-XX:G1NewSizePercent

-XX:G1MaxNewSizePercent

-XX:SurvivorRatio=8

-XX:+PrintAdaptiveSizePolicy

垃圾收集算法

YoungGC：复制算法

MixedGC：复制算法

FullGC：标记清理 + 压缩整理 = 类似标记整理算法，多线程

GC活动周期

常用参数

-XX:+UseG1GC

-XX:MaxGCPauseMillis

-XX:InitiatingHeapOccupancyPercent=45

-XX:G1HeapWastePercent=5

-XX:G1OldCSetRegionThresholdPercent=10

-XX:G1MixedGCCountTarget=8

-XX:G1ReservePercent

CMS对比G1

内存划分

垃圾收集算法

GC活动周期

三色标记算法的优化（了解）

CMS：Incremental Update

所以在重新标记还会从头开始遍历一遍

内存越大越慢

G1：SATB（Snapshot At The Beginning）

还要结合RSet

ZGC：Colored Pointers（颜色指针）

通用参数

堆

-Xms1g

-Xmx1g

日志

-XX:+PrintGC

-XX:+PrintGCDetails

-XX:+PrintGCDateStamps

-XX:+PrintGCCause

-XX:+PrintTenuringDistribution

-XX:+PrintAdaptiveSizePolicy

-XX:+PrintGCApplicationStoppedTime

-XX:+PrintGCApplicationConcurrentTime

-XX:+PrintSafepointStatistics

-XX:PrintSafepointStatisticsCount=1

-XX:+PrintReferenceGC

打印清理各类引用的时长

尤其注意FinalReference，重写了finalize方法

-Xloggc:/opt/java/xx/xx.gc

OOM

-XX:+HeapDumpOnOutMemoryError

-XX:HeapDumpPath=/opt/heap/xx.hprof

TLAB

-XX:+UseTLAB

-XX:TLABSize=x

-XX:+PrintTLAB

类加载

-verbose:class

对象晋升

-XX:MaxTenuringThreshold=15

-XX:TargetSurvivorRatio=50，动态年龄判定用，你懂得

-XX:PretenureSizeThreshold=0，默认0，不管多大都优先则Eden分配

禁用System.gc()

-XX:+DisableExplictGC

关于YoungGC

触发条件

Eden满了

对于G1

-XX:G1MaxNewSizePercent

-XX:SurvivorRatio

-XX:MaxGCPauseMillis

YoungGC过于频繁

统计单位时间产生的对象的速度

是否是必要的对象在产生

这个问题一般很简答，就是Eden小了

YoungGC耗时过长

GCRoot存活对象标注？

-XX:+PrintReferenceGC

新生代空间太大

对象引用链较长，可达性分析时间长

复制存活对象耗时？

GC时晋升的对象，存留的对象和回收的对象具体值

新生代Survivor区太小，清理后剩余的对象不能装进去需要移动到老年代，造成移动开销

存活对象太多

copy到s区

移动到老年代，动态年龄

是否有大对象

如果设置了总是在eden分配对象，gc时大对象很可能会导致动态年龄晋升到老年代

系统负载高？

gc线程等待

中小公司多个java应用部署到一台服务器

gc线程切换执行

设置的gc线程多余cpu核心数

safepoint？

-XX:+PrintGCApplicationStoppedTime

-XX:+PrintSafepointStatistics

重点关注RevokeBias或者BulkRevokeBias

并发高点的情况下，线程交替进入，synchronized锁块，导致偏向锁撤销，在安全点执行

-XX:PrintSafepointStatisticsCount=1

关于FullGC

触发条件

YoungGC前，老年代可用空间小于历次YoungGC后晋升老年代对象的平均大小

YoungGC后，老年代不能容纳晋升对象

MixedGC时，没有空闲的Region可以承载存活的对象

Metaspace可用空间不足

System.gc()

FullGC之于垃圾收集器

SerialOld（老年代，单线程）-- FullGC

ParallelOld（老年代，多线程）-- FullGC

CMS（老年代，多线程）-- 2次FullGC（CMS GC过程中有两次STW）

G1（全堆，多线程）-- FullGC

FullGC过于频繁

主要是看是否有大量短生命周期的对象晋升到老年代

有对象晋升时，对象的年龄分布

FullGC时回收了多少

执行引擎

常用命令

jinfo

jstat

jstack

jmap

问题排查

GC

YoungGC过于频繁

YoungGC耗时过长

FullGC过于频繁

OOM

在jvm里可以设置几个参数，jvm一旦oom，就会导出一份内存快照

分析快照，如jhat，mat -> 大对象、长期占用的对象

常见原因

java.lang.OutOfMemoryError: Java heap space

java.lang.OutOfMemoryError: Metaspace

java.lang.StackOverflowError: 栈内存溢出

java.lang.OutOfMemoryError: Direct buffer memory

JVM调优

说个案例，详细说明过程：现象 -> 分析（工具） -> 方案 -> 实验 -> 确定

编码规范

JavaWeb

JSP

Servlet

Html

CSS

JavaScript

JQuery

模板引擎

Velocity

Freemarker

Tomcat

重构设计

设计原则

开闭原则总则

依赖倒置原则

接口隔离原则

订单接口类不要包含对用户增删改操作的接口（方法）

单一职责原则

XX接口类的单个接口（方法）不要承载过多的任务

里氏替换原则

最少知道原则

合成复用原则

常用设计模式

创建型模式

单例模式

（C）Singleton

工厂模式

（I）Product

（I）/（C）Creator

结构型模式

代理模式

（I）Subject

（C）RealSubject

（C）Proxy

装饰模式

（I）Component

（C）ConcreteComponent

（I）Decorator

适配器模式

（I）Target

（C）Adapter

（C）Adaptee

行为型模式

策略模式

（C）Context

（I）Strategy

命令模式

线程池

（C）Invoker：线程池

一点点变形，这里面既有任务接受者，也有任务

（I）Receiver：执行线程

（I）Command：任务队列

（C）Client

创建线程池

创建并且提交任务

命令开始执行任务（当然线程池这一步是线程run，不给Client控制）

责任链模式

（C）Client

构建责任链

开始过滤

（I）Handler

一个例子

Request：敏感词过滤 -> 登录认证 -> 访问频率 -> 权限控制...

以后可能扩展加解密环节

结合工厂来构建责任链很好使

观察者模式

（I）Subject

（I）Observer

一个例子就是Zookeeper

模板方法模式

（C）AbstractClass

（C）ConcreteClass

重构-改善既有代码的设计

开源框架

NET框架

Netty

从NIO到Netty

那个图

Channel

Netty Channel 对比 JDK Channel

Netty Channel 包装 JDK Channel + 非阻塞设置

EventLoop与线程模型

NioEventLoop

其实是只有一个线程的线程池

有任务队列

NioEventLoopGroup（线程池）

内部真正的工作线程不随着NioEventLoop创建而创建，而是有任务进来时，惰性创建

任务队列优化

使用JCTools提供的Queue代替JDK的LinkedBlockingQueue

JCTools根据场景对应不用前缀的Queue

猜测，核心点还是volatile+cas自旋来实现Queue

ChannelHandler与ChannelPipeline

Pipeline模式（本质上是责任链，管道+可插拔处理单元=类比JDK Stream）

例如In事件的处理（Http为例）

第一个数据处理单元（Handler）：解码器解码，按照响应的协议解析

Http -> Json

第二个数据处理单元（Handler）：转换数据结构

Json -> POJO

第三个数据处理单元（Handler）：加密字段解密

第四个数据处理单元（Handler）：业务逻辑处理器（自定义BusinessHandler）

Netty对Pipeline的优化（处理单元向后传递时跳过没有响应事件的Handler，避免空调用）

每个处理单元的Handler都有一个int类型的MASK字段，

核心工作流程

客户端：bootstrap.connect(..)/服务端：bootstrap.bind(..)

创建Channel对象

初始化Pipeline

将Channel注册到NioEventLoop中

就是将Netty Channel中维护的JDK NIO Channel注册到NioEventLoop中维护的JDK NIO Selector对象中

NioEventLoop的工作原理（包装的Selector，很好理解）

Selector嘛，先来个无限循环

Selector#select还是Selector#selectNow？

看循环内有没有Netty本地工作执行，这很好理解，一个阻塞，一个非阻塞嘛

处理SelectKeys集合

通过Pipeline处理，Socket事件

Mina

HttpClient

HTTPClient调用优化

httpClient复用

连接池化

长连接

MVC框架

Spring

Spring核心

Spring IOC

生命周期

循环依赖

为什么要用三级缓存？

扩展点（常用举例）

@Component + BeanPostProcessor

太多

@Component + FactoryBean

Dubbo客户端启动

@Import + Registrar

AOP

@Import + Selector

TX

@Component + ApplicationListener

Dubbo服务端启动

Spring AOP

@Import + Registrar

AspectJAutoProxyRegistrar

AnnotationAwareAspectJAutoProxyCreator

BeanFactoryAware

setBeanFactory

SmartInstantiationAwareBeanPostProcessor

postProcessBeforeInstantiation

postProcessAfterInitialization

动态代理

Spring如何选择哪种动态代理（别忘了可以强制使用CGLib）

还有哪些动态代理

不同动态代理的区别

JDK Proxy必须有接口

CGLib和javassist都是修改字节码，创建一个新的子类，如出一辙，要强说一点就是javassist的api更丰富

Spring TX

@Import + Selector

TransactionManagementConfigurationSelector

AutoProxyRegistrar

InfrastructureAdvisorAutoProxyCreator

BeanFactoryAware

setBeanFactory

SmartInstantiationAwareBeanPostProcessor

postProcessBeforeInstantiation

postProcessAfterInitialization

ProxyTransactionManagementConfiguration

transactionAdvisor

transactionAttributeSource（识别@Transaction，并解析其属性）

transactionInterceptor

txManager

动态代理

Spring MVC

Spring 源码

为什么读Spring源码？

设计模式的优秀运用

扩展点优秀设计思想

有利于工作中的排错

SpringBoot

SpringCloud

注册中心

配置中心

服务调用

服务网关

服务治理

Struts

ORM框架

MyBatis

四层架构

接口层

数据处理层

参数解析，SQL解析，SQL执行，结果处理

Configuration

(Map)mappedStatements

Mapper接口方法和Mapper文件增删改查标签（MappedStatement）的映射

MapperRegistry

(Map)knownMappers

Mapper接口和MapperProxyFactory的映射

。。。

Executor

根据传递的参数，完成SQL语句的动态解析，生成BoundSql对象，供StatementHandler使用；

为查询创建缓存（一级缓存）

创建Statement对象

ParameterHandler

StatementHandler

预编译Statement对象为PreparedStatement

PreparedStatement执行数据库操作并得到结果集

ResultSetHandler

框架支撑层

数据源

连接池

事务

缓存

引导层

核心流程

SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream);

inputStream为mybatis-config.xml文件流

SqlSession session = sqlSessionFactory .openSession(true);

XxMapper xxMapper = session.getMapper(XxMapper.class); // 创建代理

创建代理对象

MapperRegistry

SqlSession#getMapper -> Configuration#getMapper -> MapperRegistry#getMapper -> MapperProxyFactory#newInstance -> Proxy.newProxyInstance(MapperProxy（Java的InvocationHandler）)

invoke方法

MappedStatement

xxMapper#增删改查

Spring集成

SqlSessionFactoryBean

sqlSessionFactoryBean.setConfigLocation：设置mybatis.xml配置信息

sqlSessionFactoryBean.setMapperLocations：设置mapper.xml配置信息

sqlSessionFactoryBean.setTypeAliasesPackage：设置实体包配置信息

sqlSessionFactoryBean.setDataSource：设置数据源

Hibernate

RPC框架

Dubbo

如何设计一个RPC框架

基本功能

服务暴露

服务引用

动态代理

服务调用

容错

负载均衡

失败重试

监控

扩展功能

服务治理

服务网关

配置中心

Dubbo IOC AOP

Dubbo SPI

Dubbo SPI和JDK SPI的对比

Dubbo是k-v，JDK是列表（会加载无用的接口实现）

@Adaptive增强@SPI，有Adaptive标注在方法上，Dubbo会先为扩展接口生产一个代理，等真正用到的时候才会加载真正的扩展接口的实现

超时时间的设置艺术

服务端设置更合理 -> 超时时间分级设置 -> 超时时间设置多少合适 -> 是否重试 -> 不宜过多重试，失败过多时降级

Dubbo性能调优

设置合理的业务线程池的大小

业务线程的拒绝策略是报错，立即失败

超时重试

阅读Dubbo源码的心得

对spring的扩展点用的很溜

扩展设计：@SPI、@Adaptive

@SPI对比JDK SPI的优势

对Invoker设计（所谓的领域驱动设计）的一点见解

Dubbo二次开发 -> 修改服务引用和调用出错时异步拉取服务配置信息

服务引用时

CustomRegistryFactory implements ZookeeperRegistryFactory

CustomRegistry implements ZookeeperRegistry

服务调用时

CustomFailoverCluster implements FailoverCluster

CustomFailoverClusterInvoker implements FailoverClusterInvoker

SpringCloud

注册中心：Eureka -> Zookeeper、Consul、Nacos

配置中心：Config + Bus -> Nacos

服务调用

负载均衡：Ribbon -> LoadBalancer

LoadBalancer还在萌芽中~

SpringCloud Alibaba的负载均衡集成的是Ribbon

动态代理：Feign -> OpenFeign

Feign(OpenFeign)只不过是用动态代理技术简化了服务调用，内部的负载均衡还是Ribbon

服务网关：Zuul -> Gateway

服务治理：Hystrix -> Resilience4j -> Sentinel

Thrift

数据存储

SQL数据库

MySQL

存储引擎

事务

锁

聚集索引和非聚集索引

库表字段

库功能要单一（业务分库）

避免一个表中有太多的列（一般不要超过30个）

一定要指定列为NOT NULL

为字段选择合适的数据类型

。。。

高效索引

分类（常见）

Hash索引

B+树索引

自适应Hash索引

索引数据结构（B+树索引）

联合索引的底层数据结构

主键索引的key为什么要设置成递增的

页分裂

磁盘碎片化

随机IO

主键索引，要存3000W数据，树的高度为多少？select要几次IO？

InnoDB一个节点大小默认是16KB

页，磁盘数据传输以页为单位，一般为4KB，一次IO读一页

为什么索引使用B+树

为什么不用B-树

B-树和B+树的区别

非叶子节点

树高度

IO

叶子节点

全量数据

有序，链表

回溯

为什么不用红黑树？

数据量 -> 树太高

超多IO

聚簇索引和非聚簇索引

数据存储方式

索引创建原则

根据条件统计所有SQL创建最优索引

选择索引选择性高的列作为索引列

优先创建联合索引（多列索引）

排序字段要出现在联合索引里，减少或避免Using filesort

当排序时记录数较多，内存中的排序 buffer满了，只能 Using filesort 进行外部排序

explain select * from table_item where user_id = 2 and user_age > 20 order by item_id limit 0, 5

idx(user_id, user_age, item_id) -> 有Using filesort

idx(user_id, item_id) -> 无Using filesort

最左前缀原则：选择合适的索引列顺序

一般3个左右联合索引就够了，最好不要超过5个！

互联网的sql都很简单，这些索引基本能覆盖所有的sql

索引失效情况（B+树索引）

违反最左原则

like'%xx'

索引列计算或使用函数

索引列类型转换

高到低无效（String列用int查），低到高有效

or，慎用

要想使用or，又想让索引生效，只能将or条件中的每个列都加上索引

优化：select * from t where t.a > ? and t.b = ? or t.c = ? order by t.d desc limit 10

如果mysql估计使用全表扫描要比使用索引快,则不使用索引

<>,>,<

not in，not exist

is null

。。。

锁

MyISAM

读：共享表锁

写：排他表锁

InnoDB

共享锁（S）

排它锁（X）

意向锁

意在更细粒度（库、表、页、行）上进行加锁

InnoDB意向锁设计比较简单，其意向锁只设计表级别的意向锁

加行锁时，首先会加一个同类型的表级意向锁（S-IS；X-IX）

意向锁由InnoDB自动添加，不能人为显示加意向锁

意向锁不会阻塞除全表扫描以外的任何操作

例如，行锁升级为表锁的情况

行锁

Record Lock

Gap Lock

Next-Key Lock

Next-Key Lock退化为Record Lock的情况

隔离级别为RC

参数设置关闭Gap Lock

对唯一索引加锁

表锁

意向锁

行锁升级

读写与锁

读（select）不加任何锁（MVCC一致性读）

可以手动加锁

select ... in share mode;

加共享锁

select ... for update;

加排他锁

写（insert | update | delete）会自动加排他锁

乐观锁&悲观锁

死锁

锁和事务

锁和事务没有强关系，别绕晕了，每个增删改查都是一个事务，但只有增删改会自动加锁，查是不加锁的

事务

ACID

Atomic

事务里的一堆SQL，要么都成功，要么都失败

Consistency

库存减一个，订单就得多一条

Isolation

不同事务之间相互隔了，互不干扰

Durability

事务成功提交，数据就持久化了

隔离级别

读未提交

读已提交（MVCC）

可以解决脏读问题

可重复度（MVCC）

MVCC可以解决不可重复读问题

可以通过加锁读（锁定读）来解决幻读

select count(*) from tb where id>100 for update;或select count(*) from tb where id>100 in share mode;

由于Next-Key Lock，id>100范围都会被锁住

select count(*) from tb where id>100

串行化

事务和锁

事务和锁没有强关系，别绕晕了，每个增删改查都是一个事务，但只有增删改会自动加锁，查是不加锁的

MVCC

DB_TRX_ID、DB_ROLL_PTR

一致性读(Consistent Read) -> 读快照（undo日志中的版本）

一致性读视图ReadView

活跃事务数组（m_ids）

低水位（数组中的最小事务ID）

高水位（数组中的最大事务ID+1）

版本链（undo日志中的版本记录）

加入版本链时，数据版本为当前已经提交的最新的版本

RR：读取版本链中第一个小于等于当前事务ID的版本；RC：读取版本链中最新的版本

性能优化

explain

索引优化

SQL优化

走索引

除非万不得已，SQL都基于单表，别连表

SQL不包含计算，只做存取

计算逻辑交个业务层

各自干擅长的事情

避免大事务

。。。

分库分表

拆分信号

单表数据量太大

水平分库

可以分库解决就把库分了

分了库可以解决很多问题

水平分表

分了库单表数据依然很大

单纯的并发量上来了

水平分库

数据服务器磁盘容量满了

要么好多表

垂直分库？-> 业务拆分

要么大表

典型的列表和详情场景

垂直分表

这样主表字段减少，跟多的行可以缓存在内存中

减少磁盘IO

拆分步骤

根据容量（当前容量和增长量）评估分库分表个数

选key（均匀）

分表规则（hash或range等）

range还是hash

range：扩容简单，场景少

时间：新老数据均匀访问

空间：群体数据均匀，比如地域什么的

hash：扩容复杂，场景多

执行（一般是双写）

双写步骤

配置双写，部署

后台数据迁移任务或者工具

将老数据迁移到新库新表

校验新老数据，以老数据为准

多次往复

配置新库新表，部署

子主题

扩容（一般是双写）

水平分库

成倍扩容方案

升级从库法（见博客）

迁库扩容方案

预先分库

预先分32个库，放在4台数据库服务器上

迁移分库

数据库服务器并发上来了，新增数据库服务器，直接迁移即可

迁移数据库，DBA有现成的工具

原理就是主从复制

拆分工具

Client端jar包

Proxy中间件

注意事项

分布式全局ID

snowflake算法

非partition key查询

映射法

基因法

NoSQL法

主从同步

那个图

复制策略

异步复制

半同步复制

一般用这个，防止数据丢失（relay日志得同步刷盘）

全同步复制

并行复制（hash）

减少主从同步延时

并没有想象中的那么有效，28法则，可能热点数据都在某个或某些表

主从延迟

主从间传递binlog日志

写入relay日志

relay日志重现 -> 数据

集群架构

高可用架构

主备，主从，双主

主从一致性问题

缓存和库一致性问题

一些数据

并发支撑

主从延时

Oracle

JDBC

连接池

Druid

HikariCP

分库分表

ShardingSphere

MyCat

TDDL

NoSQL数据库

Redis

Hbase

MongoDB

测试技能

单元测试

Mock

SpringTest

压力测试

JMeter