java面试宝典

即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致。

对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。

从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。

即服务一直可用，而且是正常响应时间。系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。

即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，对于用户而言并没有什么体验上的影响。

响应时间上的损失: 正常情况下，处理用户请求需要 0.5s 返回结果，但是由于系统出现故障，处理用户请求的时间变为 3 s。

系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的部分非核心功能无法使用。

数据同步允许一定的延迟

系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态，不要求实时

Nginx

HAproxy

LVS

当前日期和时间 时间戳

时钟序列。 计数器

全局唯一的IEEE机器识别号，如果有网卡，从网卡MAC地址获得，没有网卡以其他方式获得。

代码简单，性能好（本地生成，没有网络消耗），保证唯一（相对而言，重复概率极低可以忽 略）

每次生成的ID都是无序的，而且不是全数字，且无法保证趋势递增。

UUID生成的是字符串，字符串存储性能差，查询效率慢，写的时候由于不能产生顺序的append 操作，需要进 行insert操作，导致频繁的页分裂，这种操作在记录占用空间比较大的情况下，性 能下降比较大，还会增加读 取磁盘次数

UUID长度过长，不适用于存储，耗费数据库性能。

ID无一定业务含义，可读性差。

有信息安全问题，有可能泄露mac地址

优点

缺点

优点

缺点

每个毫秒值包含的ID值很多，不够可以变动位数来增加，性能佳（依赖workId的实现）

时间戳值在高位，中间是固定的机器码，自增的序列在低位，整个ID是趋势递增的

能够根据业务场景数据库节点布置灵活挑战bit位划分，灵活度高

强依赖于机器时钟，如果时钟回拨，会导致重复的ID生成，所以一般基于此的算法发现时钟回拨， 都会抛异常处 理，阻止ID生成，这可能导致服务不可用。

第一阶段（ prepare ） ：每个参与者执行本地事务但不提交，进入 ready 状态，并通知协调者已经准备就绪。

第二阶段（ commit ） 当协调者确认每个参与者都 ready 后，通知参与者进行 commit 操作；如果有参与者 fail ，则发送 rollback 命令，各参与者做回滚。

问题

第一阶段：CanCommit阶段，协调者询问事务参与者，是否有能力完成此次事务。

第二阶段：PreCommit阶段，此时协调者会向所有的参与者发送PreCommit请求，参与者收到后开始执行事务操作。参与者执行完事务操作后（此时属于未提交事务的状态），就会向协调者反馈“Ack”表示我已经准备好提交了，并等待协调者的下一步指令。

第三阶段：DoCommit阶段， 在阶段二中如果所有的参与者节点都返回了Ack，那么协调者就会从“预提交状态”转变为“提交状态”。然后向所有的参与者节点发送"doCommit"请求，参与者节点在收到提交请求后就会各自执行事务提交操作，并向协调者节点反馈“Ack”消息，协调者收到所有参与者的Ack消息后完成事务。 相反，如果有一个参与者节点未完成PreCommit的反馈或者反馈超时，那么协调者都会向所有的参与者节点发送abort请求，从而中断事务。

如果事务执行成功，则commit，消息中间件将消息下发至消费端（commit前，消息不会被消费）

如果事务执行失败，则回滚，消息中间件将这条prepare消息删除

最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心，服务生产者将自己提供的服务注册到Zookeeper中心，服务的消费者在进行服务调用的时候先到Zookeeper中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据

leader election

ZAB协议

zookeeper为什么要这么设计？

Zookeeper中的角色有哪些？

Zookeeper节点ZNode和相关属性有哪些？

节省资源

防止脑裂

zookeeper 的 CP 模型不适合注册中心

等待阻塞

同步阻塞

其他阻塞

sleep就是把cpu的执行资格和执行权释放出去，不再运行此线程，当定时时间结束再取回cpu资源，参与cpu 的调度，获取到cpu资源后就可以继续运行了。而如果sleep时该线程有锁，那么sleep不会释放这个锁，而 是把锁带着进入了冻结状态，也就是说其他需要这个锁的线程根本不可能获取到这个锁。也就是说无法执行程 序。如果在睡眠期间其他线程调用了这个线程的interrupt方法，那么这个线程也会抛出 interruptexception异常返回，这点和wait是一样的。

在Java中，堆是Java虚拟机所管理的内存中最大的一块，是所有线程共享的一块内存区域，在虚拟机启动时创建。堆所存在的内存区域的唯一目的就是存放对象实例，几乎所有的对象实例以及数组都在这里分配内存。

Spring框架在事务开始时会给当前线程绑定一个Jdbc Connection,在整个事务过程都是使用该线程绑定的 connection来执行数据库操作，实现了事务的隔离性。Spring框架里面就是用的ThreadLocal来实现这种 隔离

当hreadLocalMap的key为强引用回收ThreadLocal时，因为ThreadLocalMap还持有ThreadLocal的强引用，如果没有手动删除，ThreadLocal不会被回收，导致Entry内存泄漏。

当ThreadLocalMap的key为弱引用回收ThreadLocal时，由于ThreadLocalMap持有ThreadLocal的弱引用，即使没有手动删除，ThreadLocal也会被回收。当key为null，在下一次ThreadLocalMap调用set(),get()，remove()方法的时候会被清除value值。

关键字： synchronized

关键字： volatile、synchronized、final

关键字： volatile、synchronized

AbortPolicy直接抛出异常，默认策略；

CallerRunsPolicy：用调用者所在的线程来执行任务；（即创建次任务的线程）

DiscardOldestPolicy：丢弃阻塞队列中靠最前的任务，并执行当前任务；

DiscardPolicy：直接丢弃任务；

countDown()

await()

开启多个线程分块下载一个大文件，每个线程只下载固定的一截，最后由另外一个线程来拼接所有的分段。

应用程序的主线程希望在负责启动框架服务的线程已经启动所有的框架服务之后再执行。

确保一个计算不会执行，直到所需要的资源被初始化。

多线程计算

acquire()

release()

可以用于做流量控制，特别是公用资源有限的应用场景，比如数据库连接

监视器锁（monitor）是依赖于底层的操作系统的Mutex Lock来实现的，而操作系统实现线程之间的切换时需要从用户态转换到核心态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，这也是为什么早期的synchronized效率低的原因

作用于代码块

作用于实例方法

作用于静态方法

作用于方法(显式同步)

作用于代码块(隐式同步)

ObjectMontior

线程的中断操作对于正在等待获取的锁对象的synchronized方法或者代码块并不起作用

在使用notify/notifyAll和wait这3个方法时，必须处于synchronized代码块或者synchronized方法中

notify/notifyAll和wait方法都依赖于monitor

Mark Word

Class Metadata Address

没有拿到锁的就在外边等待循环（ 自旋）

锁的力度

Doug Lea大师创作的用来构建锁或者其他同步组件（信号量、事件等）的基础框架类

同步状态管理、线程的排队、等待与唤醒等

模板方法模式

独占

共享

CLH队列

一个线程完成操作后就通过信号量通知其它线程

DI

日志

缺点：需要直到要增强的方法的类才能继承

缺点：需要有接口，这个接口下除了要增强的方法外别的方法也要实现

JDK

CGLIB

@Transactional 只能用于 public 的方法上，否则事务不会失效，如果要用在非 public 方法上，可 以开启 AspectJ 代理模式。

手动装配：以value或ref的方式明确指定属性值都是手动装配。 需要通过‘ref’属性来连接bean。

Cutomer的属性名称是person，Spring会将bean id为person的bean通过setter方法进行自动装 配。 <bean id="cutomer" class="com.xxx.xxx.Cutomer" autowire="byName"/> <bean id="person" class="com.xxx.xxx.Person"/>

构造器的循环依赖

属性的循环依赖

Java的引用传递，当我们获取到对象的引用时，对象的field或属性是可以延后设置的（构造器必须是在获取引用之前）

Bean在创建的时候可以给该Bean加标记，如果递归调用回来发现，Bean正在创建中的话，即说明了循环依赖了

三级缓存----不管是不是循环依赖都有三级缓存

先尝试从单例对象缓存获取Bean

单例缓存中未取到，且Bean正在创建中，尝试从提前曝光的单例对象缓存中获取Bean

提前曝光的缓存中未取到，且允许singletonFactories通过getObject()获取，就从对象工厂缓存获取

单例对象被创建，未完成初始化，提前曝光，从singletonFactories中移除，并放入earlySingletonObjects中

最后删除二级和三级缓存

为什么二级缓存

为什么三级缓存

为什么Spring不能解决构造器的循环依赖？

加了美元$修饰 就可以取到car了

重写了equles方法，比较的是堆中对象的值

String a = "123";会放进常量池中

例子

自动装箱与拆箱 装箱：将基本类型用它们对应的引用类型包装起来； 拆箱：将包装类型转换为基本数据类型；

对于对象引用类型：==比较的是对象的内存地址。

对于基本数据类型：==比较的是值。如果整型字面量的值在-128到127之间，那么自动装箱时不会new新的Integer 对象，而是直接引用常量池中的Integer对象

如果final修饰的是类变量，只能在静态初始化块中指定初始值或者声明该类变量时指定初始值

如果final修饰的是成员变量，可以在非静态初始化块、声明该变量或者构造器中执行初始值

系统不会为局部变量进行初始化，局部变量必须由程序员显示初始化。因此使用final修饰局部变量时，即可以在定义时指定默认值（后面的代码不能对变量再赋值），也可以不指定默认值，而在后面的代码中对final变量赋初值（仅一次）

如果是基本数据类型的变量，则其数值一旦在初始化之后便不能更改

如果是引用类型的变量，则在对其初始化之后便不能再让其指向另一个对象。但是引用的值是可变的。

static class Node<K,V> implements Map.Entry<K,V> { 用的是map final int hash; final K key; V value; Node<K,V> next; Node(int hash, K key, V value, Node<K,V> next) { this.hash = hash; this.key = key; this.value = value; this.next = next; }

如果两个对象相等，则hashcode一定也是相同的

两个对象相等,对两个对象分别调用equals方法都返回true

两个对象有相同的hashcode值，它们也不一定是相等的

因此，equals方法被覆盖过，则hashCode方法也必须被覆盖

hashCode()的默认行为是对堆上的对象产生独特值。如果没有重写hashCode()，则该class的两个对象无论如何都不会相等（即使这两个对象指向相同的数据）

Object[] elementData-----arraylist

分支主题

分支主题

void linkLast(E e) { final Node<E> l = last; final Node<E> newNode = new Node<>(l, e, null); last = newNode; if (l == null) first = newNode; else l.next = newNode; size++; modCount++; } 链表list

存储node未使用树

超过8之后转换为树状

分支主题

jdk8开始链表高度到8、数组长度超过容量64，链表转变为红黑树，元素以内部类Node节点存在 高度变为6转换为链表

Hash表默认初始容量16（注解说必须说为2的整数次幂）方便位运算，效率更高，散列更均匀避免hash碰撞

最大Hash表容量 2的30次方

默认加载因子

1.初始化使用cas锁进行实现 2.put第一步取值判断槽，如果槽位为空，则cas放置值 3.put是否在扩容，改变当前的节点 详见超链接 4.put上面两种都不是添加synczied进行枷锁，锁的是header头对象效率会高（1.7锁的是大段效率肯定低），构建链表

对比1.7锁的大段，效率更高

继承ClassLoader实现自定义类加载器

运行时异常

非运行时异常（编译的时候就出现问题编译不过）

虚拟机栈(栈帧中的本地变量表）中引用的对象

方法区中类静态属性引用的对象

方法区中常量引用的对象

本地方法栈中JNI(即一般说的Native方法)引用的对象

认识 B-Tree （B树）

认识B+Tree（B+树）

B+Tree 与 B-Tree 的几点不同

B+Tree的优势（相对B-Tree）

MyISAM 和 InnoDB 引擎索引都采用B+索引

发生同一个事物里，同一条数据两次读取值不一样

幻读指的是一个事务在前后两次查询同一个范围的时候，后一次查询看到了前一次查询没有看到的行

主库写入binlog后强制同步日志到从库，所有的从库都执行完成后才返回给客户端，但是很显然这个方式的话性能会受到严重影响。

和全同步不同的是，半同步复制的逻辑是这样，从库写入日志成功后返回ACK确认给主库，主库收到至少一个从库的确认就认为写操作完成。

覆盖索引（Covering Index）

SIMPLE： 表示此查询不包含 UNION 查询或子查询

PRIMARY： 表示此查询是最外层的查询（包含子查询）

SUBQUERY： 子查询中的第一个 SELECT

UNION： 表示此查询是 UNION 的第二或随后的查询

DEPENDENT UNION： UNION 中的第二个或后面的查询语句, 取决于外面的查询

UNION RESULT, UNION 的结果

DEPENDENT SUBQUERY: 子查询中的第一个 SELECT, 取决于外面的查询. 即子查询依赖于外层查询的结果.

DERIVED：衍生，表示导出表的SELECT（FROM子句的子查询）

const：通过索引一次命中，匹配一行数据

system: 表中只有一行记录，相当于系统表；

eq_ref：唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配

ref: 非唯一性索引扫描,返回匹配某个值的所有

range: 只检索给定范围的行，使用一个索引来选择行，一般用于between、<、>；

index: 只遍历索引树；

ALL: 表示全表扫描，这个类型的查询是性能最差的查询之一。 那么基本就是随着表的数量增多，执行效率越慢。

using filesort ：表示 mysql 对结果集进行外部排序，不能通过索引顺序达到排序效果。一般有using filesort都建议优化去掉，因为这样的查询 cpu 资源消耗大，延时大。

using index：覆盖索引扫描，表示查询在索引树中就可查找所需数据，不用扫描表数据文件，往往说明性能不错。

using temporary：查询有使用临时表, 一般出现于排序， 分组和多表 join 的情况， 查询效率不高，建议优化。

using where ：sql使用了where过滤,效率较高。

1、整个Redis数据库将只包含一个文件 dump.rdb，方便持久化。

2、容灾性好，方便备份。

3、性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，所以是 IO 最大化。使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis 的高性能

4.相对于数据集大时，比 AOF 的启动效率更高。

1、数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候)

2、由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

1、数据安全，Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。

2、通过 append 模式写文件，即使中途服务器宕机也不会破坏已经存在的内容，可以通过 redischeck-aof 工具解决数据一致性问题。

3、AOF 机制的 rewrite 模式。定期对AOF文件进行重写，以达到压缩的目的

1、AOF 文件比 RDB 文件大，且恢复速度慢。

2、数据集大的时候，比 rdb 启动效率低。

3、运行效率没有RDB高

集群监控：负责监控 redis master 和 slave 进程是否正常工作。

消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。

故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。

配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。

故障转移时，判断一个 master node 是否宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举

即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的

哨兵通常需要 3 个实例，来保证自己的健壮性。

哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。

对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。

通过哈希的方式，将数据分片，每个节点均分存储一定哈希槽(哈希值)区间的数据，默认分配了16384 个槽位

每份数据分片会存储在多个互为主从的多节点上

数据写入先写主节点，再同步到从节点(支持配置为阻塞同步)

同一分片多个节点间的数据不保持强一致性

读取数据时，当客户端操作的key没有分配在该节点上时，redis会返回转向指令，指向正确的节点

扩容时需要需要把旧节点的数据迁移一部分到新节点

优点

缺点

优势在于非常简单，服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强

由于sharding处理放到客户端，规模进一步扩大时给运维带来挑战。客户端sharding不支持动态增删节点。服务端Redis实例群拓扑结构有变化时，每个客户端都需要更新调整。连接不能共享，当应用规模增大时，资源浪费制约优化

如果从节点保存的runid与主节点现在的runid相同，说明主从节点之前同步过，主节点会继续尝试使用部分复制(到底能不能部分复制还要看offset和复制积压缓冲区的情况)；

如果从节点保存的runid与主节点现在的runid不同，说明从节点在断线前同步的Redis节点并不是当前的主节点，只能进行全量复制