金山办公-服务器端Java一面

前言

面试官哪里很吵，特别吵。面试开始时，叫我等一会儿，应该是现看我简历，过了几分钟，问了我一些基本情况，比如除了Java还学过其他什么语言、为什么本科就出来找工作这些。

就第一个问题，我就有点怀疑这个面试官可能不是Java的，后面的面试也更加印证了我的想法，因为全程没有Java八股，问的都是一些计算机基础、中间件。

操作系统

（楼主面试真的很少遇到操作系统的八股，大多都是线程、进程相关的，导致很少去深入看操作系统的八股，导致有点被爆锤）

1.了解操作系统的内存管理吗，缺页中断说一下

2.了解VSS吗（？？？）

3.进程的通信方式

4.了解TLB吗

5.进程切换，会刷新TLB吗

6.Linux文件系统

7.操作系统内存分配

8.那些操作会触发进程调度

9.操作系统内存管理

计网知识

1.TCP可靠性是如何实现的

2.断开连接中CLOSE-WAIT状态在哪一方？

场景：在服务器端有大量连接出现了CLOSE-WAIT转态，可能是什么原因

3.HTTPS，使用的加密算法

4.客户端发送数据到服务器端，内容发生了几次拷贝

这个问题，我一开始回答需要从文件系统拷贝到内核缓冲区，然后拷贝到用户缓冲区，发生两次

面试官说，假设内容已经在用户缓冲区，发送需要几次拷贝

redis

1.redis基本数据结构，那些使用的比较多（答Set）

2.Set底层数据结构

3.场景：假设有100万的键，不重复，平均大小10B，问在redis服务器上存下这些数据大概需要多大空间（结合跳表的结构回答了）

4.redis对String类型操作的指令周期

5.LRU，假设要保证O（1）的查询效率，选择什么数据结构

数据库

1.什么是幻读

2.InnoDB默认事务隔离级别

3.一条Update语句执行过程（还好刚看过，贴个答案在下面）

具体更新一条记录 UPDATE t_user SET name = 'xiaolin' WHERE id = 1; 的流程如下:

执行器负责具体执行，会调用存储引擎的接口，通过主键索引树搜索获取 id = 1 这一行记录：

如果 id=1 这一行所在的数据页本来就在 buffer pool 中，就直接返回给执行器更新；
如果记录不在 buffer pool，将数据页从磁盘读入到 buffer pool，返回记录给执行器。

执行器得到聚簇索引记录后，会看一下更新前的记录和更新后的记录是否一样：

如果一样的话就不进行后续更新流程；
如果不一样的话就把更新前的记录和更新后的记录都当作参数传给 InnoDB 层，让 InnoDB 真正的执行更新记录的操作；

开启事务， InnoDB 层更新记录前，首先要记录相应的 undo log，因为这是更新操作，需要把被更新的列的旧值记下来，也就是要生成一条 undo log，undo log 会写入 Buffer Pool 中的 Undo 页面，不过在内存修改该 Undo 页面后，需要记录对应的 redo log。
InnoDB 层开始更新记录，会先更新内存（同时标记为脏页），然后将记录写到 redo log 里面，这个时候更新就算完成了。为了减少磁盘I/O，不会立即将脏页写入磁盘，后续由后台线程选择一个合适的时机将脏页写入到磁盘。这就是 WAL 技术，MySQL 的写操作并不是立刻写到磁盘上，而是先写 redo 日志，然后在合适的时间再将修改的行数据写到磁盘上。
至此，一条记录更新完了。
在一条更新语句执行完成后，然后开始记录该语句对应的 binlog，此时记录的 binlog 会被保存到 binlog cache，并没有刷新到硬盘上的 binlog 文件，在事务提交时才会统一将该事务运行过程中的所有 binlog 刷新到硬盘。
事务提交（为了方便说明，这里不说组提交的过程，只说两阶段提交）：

prepare 阶段：将 redo log 对应的事务状态设置为 prepare，然后将 redo log 刷新到硬盘；
commit 阶段：将 binlog 刷新到磁盘，接着调用引擎的提交事务接口，将 redo log 状态设置为 commit（将事务设置为 commit 状态后，刷入到磁盘 redo log 文件）；

至此，一条更新语句执行完成。