JAVA后端开发面试宝典

底层为：数组+int（size）

达到阈值后进行扩容，如果能预先知道数量最好给定初始容量，否则扩容可能浪费内存空间

遍历、新增、删除都是直接曹祖数组，删除新增可能会进行copy数组

底层为：Node对象（data，next）

遍历时需要从前到后一次查找，删除新增比较快

底层为：数组+链表（或红黑树）

每一个Key进来后进行Hash，然后通过位运算映射到Hash数组上，当Hash位运算后的下标冲突时，会在这个位置产生一个
链表，当链表达到8位的时候会转化红黑树，红黑树数组达到6位时会转化为链表

扩容：HashMap位数都是2的次方，这是由于Hash找位算法决定的。当HashMap数据容量达到（数组长度*加载因子）时就
会考虑扩容

为什么选择红黑树而不是val，b，b+呢？（红黑树内存性能比b,b+好，删除性能比val好）
为什么链表->红黑树 与 红黑树->链表 分别是8和6而不是一样？（8是红黑树与链表的性能分界点，不都取8是因为如果hash冲突在8附近容易不断转换）
为什么加载因子时0.75呢（泊松分布有关）
为什么初始容量和扩容都是2的倍数呢 （（n-1)&hash算法决定 n-1 为奇数，在二进制中更容易分散）

底层：数组+链表（或红黑树），hash使用cas比较，其他地方使用synchronized加锁

底层：多个副本数组，新增、修改、删除都会copy数组副本到volatile修饰的数组（保证可见性）。因此新增、修改、删除消耗很大，一般用于增删改少而查询很多的并发场景

ArrayBlockingQueue

LinkedBlockingQueue

线程是cpu执行的最小单元。有单独的计数器，线程间数据可以共享

单核状态下多线程，cpu不断切换运行，会有上下文切换，因此并不是线程越多越好

线程状态：New，Runable，Running，Blocked，Terminated

线程池7个参数

创建流程

ThreadPoolExecuter实现原理

SchedulePoolExecuter实现原理

CountDownLuach

Semaphore

java很多并发处理都继承他

直接操作进行比较替换数据，替换成功返回true

升级过程

无法保证原子性，可以保证有序性和一致性

禁止指令重排序

保证可见性

java对象存放内存，个线程共享

java运行指令存放，线程独有

类信息，常量，静态变量

程序运行记录，cpu切换时读取记录，线程独有

native所有

jmap -heap [pid]

#dump内存日志
jmap -dump:format=b,file=[filename.prof] [pid]

#查看对象分布信息
jmap -histo [pid]

#[ms]：多少毫秒打印一次 ，[times]打印多少次 
jstat -gc [pid] [ms] [times]

jstack [pid] >> [file.text]

加密过程

read

select/poll

epoll

分隔符解码器：FixedLengthFrameDecoder

分隔符解码器：DelimiterBasedFrameDecoder

header中有长度定义数据长度：LengthFieldBasedFrameDecoder

IdleStateHandler

处理消息的服务器

生产者，生产消息方，属于客户端，需要连接broker

消费者，消费消息方，属于客户端，需要连接broker

主题，发送消息的逻辑单位，一种业务可以定义一个topic，
生产、消费都需要按照topic处理

每个topic对应多个patition，topic是逻辑单位，patition就是
topic下的多个真实队列，一个topic有多少个patition就可以实现多少并发生产和消费

消费者的个数不能超过patition个数，超过了也没任何用。
消费者=patition，那么每个消费者对应一个patition，减少消费者时会reblance
消费者<patition，一个消费者可能对应多个patition，当新增消费者或者减少消费者时会出现reblance

每个 consumer 都属于一个 consumer group，每条消息只能被 consumer group 的一个 Consumer 消费，但可以被多个 consumer group 消费。

副本，每一个主题都需要定义有副本，副本会单独存放topic下数据
防止数据丢失，存放逻辑按照patition处理

消息，kafka中最基本的传递对象，有固定格式

真实存储数据的地方，每个patition会有多段segment，segment中存放的是消息。
当一个segment中存放的数据超过配置的大小阈值后，会重新新建一个segment，

一个连续的用于定位被追加到分区的每一个消息的序列号，最大值为64位的long大小，19位数字字符长度。
当一个topic的group下消费到某个消息时，就记录这个消息的序列号，该序列号记录到了一个固定topic中

PUT /my_index -d '{"mappings":{}}'

字段类型

分词器

分片

副本

DELETE /my_index

PUT /my_index -d '{"mappings":{}}'

POST /my_index/_search -d '{"query":{}}'

term

match

wildcard

排序sort

分页from,to

track_total_hits

bool查询

子查询

嵌套查询

类似b树

相较于b树：叶子节点无数据，最末节点由链表指针相连

all（全表扫描）

index（索引扫描）

range（索引范围查询）

eq_ref（索引精准定位）

const、system（单行记录查询）

null（无数据查询）

Using filesort（group by、order by使用了文件排序）

Using temporary（使用了临时表存数据）

Using index（覆盖索引）

Using where（如果使用索引，那么没有覆盖索引）

读未提交（会出现脏读）

读已提交（会出现不可重复读）

可重复读（会出现幻读（针对删除））

序列化

表锁

GAP锁

行锁

共享锁（S）

独占锁（X）

每一个增删改都会记录到日志版本链中，按照先后顺序形成一个链表

每开始一个事务会生成当时的最大事务id、最小活跃事务id、活跃事务id集合的readview

1、版本链中的事务id<最小活跃事务id，
那么这个事务就是已提交事务就查询该版本数据

2、如果版本链中的事务id >= 最小活跃事务id
& 版本链中的事务id <= 最大活跃事务id，此时分情况而定

3、版本链中的事务id>最大事务id，
那么在当时当时创建readview时还没有，肯定不能要

aof

rdb

aof&rdb一起使用

noeviction：当内存使用达到阈值的时候，所有引起申请内存的命令会报错。
allkeys-lru：在主键空间中，优先移除最近未使用的key。(推荐)
volatile-lru：在设置了过期时间的键空间中，优先移除最近未使用的key。
allkeys-random：在主键空间中，随机移除某个key。
volatile-random：在设置了过期时间的键空间中，随机移除某个key。
volatile-ttl：在设置了过期时间的键空间中，具有更早过期时间的key优先移除。

raft

hash槽

扩容

一台机器或一个进程代表一个broker，即一个实例

CommitLog

ConsumerQueue

简单的注册中心

消费者数量没<该topic的ConsumerQueue时新增消费者会出现Rebalance

消费者数量>该topic的ConsumerQueue时 某些消费者会无法接受消息

对于一个topic一个消费者可以消费多个ConsumerQueue，但是ConsumerQueue只能属于一个消费者

一个topic可能会有多个ConsumerQueue，这些ConsumerQueue可能分散在多个broker上

同步发送，等待返回SEND_OK才算成功

异步发送，可以在发送时记录数据库日志，在发送回调中修改状态

同步刷盘flushDiskType = SYNC_FLUSH

slave也配置同步刷盘

master同步复制 brokerRole=SYNC_MASTER

消费队列中回复成功

消费者自己维护ConsumerQueue的offset

try

commit

cancel

使用mq实现最终一致性