面试记录（java）

MySQL相关问题

1. MySQL主从同步

1.1 主从同步的方式

• 异步
• 同步

1.2 主从同步的好处

• 通过增加从服务器增加了数据库的性能，在主服务器上执行写入和更新，从服务器提供读。
• 提高数据安全，从服务器可用于备份
• 高可用

1.3 主从流程和原理

主要涉及三个线程，一个运行在主节点（log dump thread），其余两个运行在从节点（I/O thread、SQL thread）。

• log dump thread—— 主节点为其创建一个log dump 线程，用于发送和读取bin-log的内容。在读取bin-log的操作时，log dump线程会对主节点的bin log加锁，当读取完成，在发送给从节点之前，锁会被释放。主节点会为自己的每一个从节点创建一个log dump 线程。
• I/O线程—— 当从节点执行‘start-slave’ 命令之后，从节点会创建一个I/O线程用来连接主节点，请求主库更新的bin log。I/O线程接收到主节点的bin dump线程发送来的更新之后，保存在本地relay-log中，并将bin-log的文件名和位置保存到master-info文件中，以便在下一次读取的时候能够清楚的告诉Master。
• SQL线程—— SQL线程负责读取relay -log中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。

1.4 MySQL主从的复制方式

• Statement（基于SQL语句的复制）——优点是只需要记录会修改数据的sql语句到bin-log中，减少了bin-log的日志量，节约了I/O。缺点是对于某些函数会导致数据不一致，因为需要保存上下文。
• ROW（基于行的复制）—— 记录了哪条数据被修改了，修改成什么样了。优点是不会出现无法复制的情况，缺点是会产生大量的日志，尤其是修改table的时候会让日志暴增，同时增加了binlog的同步时间。
• Mixed（混合模式复制）对于一般模式使用statement，对于无法使用statement的使用row。

1.5 主从延迟

• 主库针对写操作，顺序写bin-log。从库顺序读bin-log，在本地取到在本地原样执行，可能存在锁的竞争。
• 数据库读写压力太大，CPU计算负荷大，网卡负荷大，读写binlog性能受到影响，网络传输延迟。
• 延迟解决——（1）加入缓存层，减少读写压力 （2）硬件升级 （3）并行复制。

2. 分库分表迁移

3. binlog恢复

4. MySQL事务隔离级别

5. ACID

• A（原子性）：原子性是指整个数据库事务是不可分割的工作单位。只有使事务中所有的数据库操作执行成功，才算整个事务成功。
• C（一致性）：一致性指事务将数据库从一种状态转变为下一种一致的状态。在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。
• I（隔离性）：一个事务的影响在该事务提交前对其他事务都不可见——通过锁来实现
• D（持久性）：事务一旦提交，其结果就是永久性。即使发生宕机，数据库也能恢复。

6. redo、undo、bin写的顺序

• redo：当一个事务执行时，会往InnoDB存储引擎的日志缓冲里插入事务日志；当事务提交时，必须将InnoDB存储引擎的日志缓冲写入磁盘。也就是写数据之前，需要先写日志-------WAL（预写日志方式）。
• undo：对于数据库进行修改，数据库不但会产生redo，而且会产生一定量的undo。redo存放在重做日志文件中，undo存放在数据库内部的一个特殊段——undo段。

7. 索引数据结构比较

8. 索引的优化

mysql在索引使用的时候一般都会把数据最小的字段放前面，也就是最能确定结果的字段，因为索引的第一个字段的检索范围是最小的，然后根据可以可以确定数据范围的大小依次排序。

9. a，b，c建立索引，c=1，b>=1，a in 1,2，3索引怎么走

10. 唯一索引和普通索引查找速度、插入速度

11. 索引的插入

• B+树是为了磁盘或者其他直接存取辅助设备而设计的一种平衡查找树，在B+树中，所有的记录都是按健值的大小顺序存放在同一层的叶节点中，个叶节点指针进行连接。
• B+树的插入必须保证插入后叶节点中的记录依然排序；

12. 2PC， 3PC

• 2PC被认为是一种一致性协议，用来保证分布式系统数据的一致性。目前绝大部分的关系型数据库都是采用二阶段提交协议来完成分布式事务处理。

12.1 2PC

阶段一：提交事务请求

1. 事务询问：协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
2. 执行事务：各参与者节点执行事务操作，并将Undo和Redo信息进入事务日志中。
3. 各参与者向协调者反馈事务询问的响应：如果参与者成功执行了事务，就反馈YES，如果没有成功就返回NO响应，表示事务不可以执行。
   阶段一可以理解为投票阶段，即参与投票标明是否要继续执行接下来的事务提交操作。

阶段二：执行事务提交

协调者根据各参与者的反馈情况来决定最终是否可以进行事务预提交操作，正常情况下，包含以下两种情况：

执行事务提交

假如协调者从所有的参与者获得反馈都是YES，那么就会执行事务提交

1. 发送提交请求：协调者向所有的节点发出Commit请求
2. 事务提交：参与接收到Commit请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源
3. 反馈事务提交：参与者在完成事务提交之后，向协调者发送ACK消息
4. 完成事务：协调者接收到所有参与者反馈的ACk消息后，完成事务

中断事务

任何一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者无法接收到所有参与者的反馈信息，那么就会中断事务。

优缺点

• 优点：原理简单，实现方便
• 缺点：
  （1）同步阻塞：二阶段提交协议存在最明显也是最大的问题就是同步阻塞，所有参与该事物操作的逻辑处于阻塞状态，也就是说，各个参与者在等待其他参与者响应的过程中，将无法进行任何操作。
  （2）单点问题：一旦协调者出现问题，那么其他参与者都会处于锁定事务资源的状态，将无法继续完成事务操作。如果在阶段二出现问题，那么可能会出现不一致情况。

12.2 3PC

• 3PC，其将二阶段提交协议的“提交事务请求”过程一分为二，形成了CanCommit、PreCommit和DoCommit。

阶段一：CanCommit

• 事务询问：协调者向所有的参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
• 各参与者向协调者反馈事务询问的响应：参与者接收来自协调者的canCommit请求后，正常情况下，如果其自身认为可以顺利执行事务，那么就会反馈Yes响应，并进入预备状态。

阶段二：PreCommit

在阶段二中，协调者会根据各参与者的反馈情况来决定是否可以进行事务的PreCommit操作，正常情况下，包含两种可能。

执行事务预提交

• 发送预提交请求：协调者向所有参与者节点发出PreCommit的请求，并进入Prepared阶段。
• 事务预提交： 参与者接收到PreCommit请求后，并将Undo和Redo信息记录到事务日志中。
• 各参与者向协调者反馈事务执行的响应：如果参与者成功执行了事务操作，那么就会反馈给协调者Ack响应，同时等待最终的指令：提交或中止。

中断事务

假如任何一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无发接收到所有参与者反馈响应，那么就会中断事务。

阶段三：doCommit

该阶段将进行真正的事务提交，会存在以下两种可能的情况

执行提交

• 发送提交请求：进入这一阶段，假设协调者处于正常工作状态，并且它接收到了来自所有参与者的ACK响应，那么它将从预提交状态转换到提交状态，并向所有的参与者发送docommit请求。
• 事务提交
• 反馈事务提交结果
• 完成事务

中断事务

13. MySQL物理备份保证一致性

14. 逻辑备份保证一致性

15. MySQLdump 和 xtrabackup的原理及流程

xtrabackup：

• xtrabackup是用来备份InnoDB表的，不能备份非InnoDB表，和 mysql server没有交互；备份中我们需要使用innobackupex，虽然我们可能自己不用MyISAM表，但是mysql库下的系统表是MyISAM的，因此备份基本都通过innobackupex命令进行；
• 流程
  （1）fork出一个进程，启动xtabackup进程，然后就xtrabackup备份完ibd数据文件；
  （2）xtrabackup 在备份 InnoDB 相关数据时，是有2种线程的，1种是 redo 拷贝线程，负责拷贝 redo 文件，1种是 ibd 拷贝线程，负责拷贝 ibd 文件；redo 拷贝线程只有一个，在 ibd 拷贝线程之前启动，在 ibd 线程结束后结束。xtrabackup 进程开始执行后，先启动 redo 拷贝线程，从最新的 checkpoint 点开始顺序拷贝 redo 日志；然后再启动 ibd 数据拷贝线程，在 xtrabackup 拷贝 ibd 过程中，innobackupex 进程一直处于等待状态（等待文件被创建）。
  （3）xtrabackup 拷贝完成idb后，通知 innobackupex（通过创建文件），同时自己进入等待（redo 线程仍然继续拷贝）;
  （4）innobackupex 收到 xtrabackup 通知后，执行FLUSH TABLES WITH READ LOCK (FTWRL)，取得一致性位点，然后开始备份非 InnoDB 文件（包括 frm、MYD、MYI、CSV、opt、par等）。拷贝非 InnoDB 文件过程中，因为数据库处于全局只读状态，如果在业务的主库备份的话，要特别小心，非 InnoDB 表（主要是MyISAM）比较多的话整库只读时间就会比较长，这个影响一定要评估到。
  （5）当 innobackupex 拷贝完所有非 InnoDB 表文件后，通知 xtrabackup（通过删文件） ，同时自己进入等待（等待另一个文件被创建）；
  （6）xtrabackup 收到 innobackupex 备份完非 InnoDB 通知后，就停止 redo 拷贝线程，然后通知 innobackupex redo log 拷贝完成（通过创建文件）；
  （7）innobackupex 收到 redo 备份完成通知后，就开始解锁，执行 UNLOCK TABLES；
  （8）最后 innobackupex 和 xtrabackup 进程各自完成收尾工作，如资源的释放、写备份元数据信息等，innobackupex 等待 xtrabackup 子进程结束后退出。

16. explain

• 在日常工作中，我们有时会开启慢查询去记录一些执行时间比较久的SQL语句，找出这些SQL语句并不意味着完事了，这时候常常需要explain命令来查看。
• 读取表的顺序
• 哪些索引能被使用
• 读取数据操作的操作类型
• 表之间的引用
• 每张表有多少行被物理查询
• id ： select 查询的序列号，包含一组数字，表示查询中执行select子句或操作表的顺序
• partition：匹配的分区
• type: 访问的类型
• key：实际用到的索引
• key_len ：表示索引中使用的字节数
• ref：显示索引的哪一列被使用了
• rows：根据表统计信息及索引选用情况，大致估算出找到所需记录读取的行数
• filtered：查询表占表的百分比。

17. 几种日志

java相关问题

1. java的内存模型

• java虚拟机规划试图定义一种java内存模型来屏蔽掉各种硬件和操作系统的内存访问差异，以实现让java程序在各种平台下都能到达一种的并发效果。在此之前C、C++直接使用物理硬件（操作系统的内存模型），因此会由于不同平台上内存模型的差异，导致出现问题。
• jMM内存模型只要就是让JAVA的并发操作不会产生歧义，同时可以获得更好的执行速度。
• JMM的主要目标是定义程序中各个变量的访问规范，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。
• JMM规定了所有的变量存储在主内存中，每条线程还有自己的工作内容，线程的工作内存中保存了该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量。不同线程之间也无法直接访问对方工作内存的变量，线程间的变量值的传递均需要通过主内存来完成。
  

内存间交互操作

1. lock（锁定）：作用于主内存的变量，它把一个变量标识为一条线程独占的状态。
2. unlock（解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。
3. read（读取）：作用于主内存的变量，从主内存中得到的变量值放入工作内存的变量副本中
4. use：它把工作内存中的一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量的值的字节码指令时会执行这个操作。
5. assign（赋值）：它把一个从执行引擎接收到的值赋值给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
6. store（存储）：作用于工作内存的变量，它把工作内存中的一个变量的值传送到主内存中，以便随后的write操作使用
7. write（写入）：作用于主内存的变量，他把store操作从工作内存中得到的变量的值放入主内存的变量
8. load（载入）:它把read操作从主内存中得到的变量值放入工作内存的变量副本中。

2. 数组存放在哪

3. 字符串存放在哪

4. 两个对象分配到同一内存池，怎么优化避免CAS和锁

5. debug原理

• INT指令，CPU支持INt指令来触发中断，中断有编号，不同的编号有不同的处理程序，INT3可以触发debugger。debugger程序在需要设置断点的位置吧指令内容替换成INT 3，这就被断住了。就可以获得这时候的环境数据来做调试。恢复就是把之前的代码换回去。
• 中断寄存器，通过中断寄存器的硬中断。

6. java线程的状态

• 新建（NEW）：创建后未启动的线程处于这种状态
• 运行 （Runable）：包括了操作线程中的Running和Ready
• 无限期等待（Waiting）：处于这种状态的进程不会被分配CPU执行时间，他们要等待被其他线程显示的唤醒。wait，join，park
• 限期等待（Timed Waitiing）：处于这种状态也不会被分配CPU执行时间，不过无需等待被其他线程唤醒，会自动唤醒。 sleep，设置了tiamout的参数。
• 堵塞（Blocked）：进程被堵塞了，阻塞状态在等待获得一个排他 锁
• 结束（Terminated）：线程已经结束执行

7. 一个线程里关闭另外一个线程

• 共享变量，设置退出标志
• 使用interrupt（）方法中断线程
• 使用stop方法强行终止线程

8. java分配大内存

9. 锁升级

10. 几种排序算法

11. 快排优化

快排代码第一便是选择基准点，刺手数据的移动根据这个基准点的大小进行调整，如果基准点选取不好，将会导致快排效率低下。

• 三数取中值和随机交换法

12. 三色标记法

• 将对象分为黑、灰、白，三种颜色
  （1）黑色：该对象已经被标记过了，且该对象下的属性也全部都被标记过了（程序所需要的对象）
  （2）灰色：该对象已经被标记过了，但该对象下的属性没有全被标记完（GC需要从此对象中去寻找垃圾）
  （3）白色：该对象没有被标记过。（对象垃圾）

13.java申请一块连续内存没有申请到怎么办

计网相关

1. TCP长连接

• 连接的保活：KeepAlive
  在一定时间内在链路上没有数据传输的情况下，TCP层将发送响应的KeepAlive探针以确定连接的可用性，探测重试10次之后，每次间隔75s，所有探测失败后，才认为当前连接已经不可用。
• Netty 心跳包

2. TCP池化技术

• 池，一种资源抽象的形象化说法。池是一组资源，可以随时使用，但不可随时地创建和释放；

3. 三次握手和四次挥手及每一个状态

5. TCP第三次握手服务端没有收到

操作系统相关

1. 进程和线程的区别，进程切换的具体流程

2. malloc

3. mmap

4. 用户态和内核态

5. 水平触发和边缘触发

6. Netty中是水平触发还是边缘触发

7. 死锁

8. 系统调用的过程

Spring

1. 循环依赖

2. 常用注解

3. springMVC请求流程

4. IOC和AOP

分布式

1. RPC和HTTP的区别

• HTTP和RPC没有明显的界限，RPC一般是企业内部实现本地调用的一种方式，HTTP只要是对外提供服务的一种方式。

2. CAP

3. paxos

4. 限流算法的优缺点

• 计数器算法：设置一个计数器对某段时间内的请求进行计数，当请求量超过某个事先设定的阈值时则触发饱和策略，拒绝用户请求。
• 漏桶算法：不管进水量多大，漏桶始终以恒定的速度往外排水，如果桶被装满则后来涌入的水会满出去。然而，始终恒定的处理速率有时候并不一定最好，对于突发的请求，在保证服务安全的前提下，应该尽最大努力去响应，这时候漏桶算法显得有些呆滞。
• 令牌桶算法：以恒定的速度发放令牌，有令牌才能响应。

5. 负载均衡算法

6. 同步RPC和异步RPC和流式

Redis

主从复制

• Redis的复制功能分为同步（sync）和命令传播两个操作：
  （1）同步操作作用于将从服务器的数据库状态更新至只服务器当前所处的数据库状态。
  （2）命令传播操作则用于在主服务器的数据库状态被修改，导致主从服务器状态出现不一致，让主从重新回到一致状态。