首页 > 字节的后端实习二面,八股盛宴!
头像
王中阳讲编程
发布于 昨天 20:02 北京
+ 关注

字节的后端实习二面,八股盛宴!

好久没分享面经了,今天来个大的---字节的后端实习二面,简直就是八股盛宴,问的太多太全面了。

面经详解

1. 数据库的隔离级别有哪些?

数据库事务隔离级别主要分为四种,从低到高依次为:

  1. 读未提交(Read Uncommitted) 允许事务读取其他事务未提交的数据,可能导致脏读、不可重复读和幻读。
  2. 读已提交(Read Committed) 只能读取其他事务已提交的数据,避免脏读,但可能出现不可重复读和幻读。是 Oracle 和 SQL Server 的默认级别。
  3. 可重复读(Repeatable Read) 确保同一事务内多次读取同一数据结果一致,避免脏读和不可重复读,但可能发生幻读。是 MySQL InnoDB 的默认级别。
  4. 串行化(Serializable) 最高隔离级别,强制事务串行执行,避免所有并发问题(脏读、不可重复读、幻读),但性能开销最大。

对比总结

读未提交

最低

读已提交

中等

可重复读

中高

串行化

最高

2. 可重复读隔离级别是通过什么机制来实现的?

可重复读隔离级别通过 MVCC(多版本并发控制)锁机制 实现:

  1. MVCC: Read View:事务启动时创建数据快照,后续所有读操作基于此快照,确保数据一致性。Undo Log:存储数据的历史版本。事务读取数据时,通过版本链找到符合快照可见性的版本。
  2. 锁机制: 行级锁:更新数据时加锁,防止其他事务修改当前行。间隙锁(Gap Lock):锁定索引范围内的间隙,防止其他事务插入新数据(解决幻读)。

示例:事务 A 启动后读取账户余额为 1000 元,即使事务 B 修改余额并提交,事务 A 再次读取仍为 1000 元。

3. 说明 MVCC(多版本并发控制)的具体实现流程

MVCC 的核心是通过数据多版本实现读写并发控制,流程如下:

  1. 隐藏字段:每行数据包含 DB_TRX_ID(最近修改的事务 ID)和 DB_ROLL_PTR(指向 Undo Log 的回滚指针)。
  2. Read View 生成:事务首次读操作时创建 Read View,记录当前活跃事务 ID 列表,用于判断数据版本的可见性。
  3. 数据读取流程:根据数据行的DB_TRX_ID与 Read View 对比:若 DB_TRX_ID 小于 Read View 中最小活跃 ID,说明数据已提交,可见。若 DB_TRX_ID 在活跃事务 ID 列表内,说明数据未提交,不可见,需沿 DB_ROLL_PTR 在 Undo Log 中查找旧版本。
  4. 写操作流程:更新数据时,将旧数据拷贝到 Undo Log,新数据覆盖原行并更新 DB_TRX_ID。
  5. 版本清理:后台线程定期清理无活跃事务引用的旧版本数据(Purge 机制)。

案例:事务 A(ID=101)更新数据时,事务 B(ID=102)通过 Read View 读取 Undo Log 中的旧版本,避免脏读。

4. 不可重复读与幻读的区别是什么?

定义

同一事务内多次读取同一数据,结果不一致

同一事务内多次查询同一条件,结果集行数不一致

原因

其他事务修改了该数据(UPDATE/DELETE)

其他事务插入或删除了符合条件的数据(INSERT/DELETE)

数据范围

单行数据

多行数据(结果集)

解决隔离级别

可重复读(通过 MVCC 固定快照)

串行化(通过间隙锁阻止插入)

示例

事务 A 两次读取用户工资,值从 1000 变为 2000

事务 A 两次查询工资=1000 的用户,从 10 条变为 11 条

5. mysql的日志都有哪些,用途?

错误日志(Error Log)

记录 MySQL 启动、运行、关闭过程中的错误和警告,用于故障排查

必须启用

慢查询日志(Slow Query Log)

记录执行时间超过阈值的 SQL,用于优化查询性能

建议启用

二进制日志(Binlog)

记录所有数据修改操作(INSERT/UPDATE/DELETE),用于主从复制和数据恢复

主库必须启用

重做日志(Redo Log)

InnoDB 特有,记录事务的物理修改,用于崩溃恢复(保证持久性)

自动启用

回滚日志(Undo Log)

存储数据修改前的版本,用于事务回滚和 MVCC

自动启用

中继日志(Relay Log)

从库存储主库同步的 Binlog,用于主从复制

从库自动启用

通用查询日志(General Log)

记录所有客户端请求(含 SQL 语句),用于审计

仅调试时临时启用

6. redo log的实现?

Redo Log 通过 Write-Ahead Logging(WAL) 机制实现事务持久性:

  1. 物理结构:固定大小的循环文件(如 ib_logfile0, ib_logfile1),写满后覆盖旧数据。Write Pos:当前写入位置;Checkpoint:已刷盘的数据位置。
  2. 写入流程:事务修改数据前,先写 Redo Log Buffer(内存)→ 提交时刷盘到 Redo Log 文件。刷盘策略由控制:1(默认):每次提交同步刷盘(强一致)0 或 2:异步刷盘(可能丢失 1 秒数据)。
  3. 崩溃恢复:重启后根据 Redo Log 中的 LSN(日志序列号)恢复未刷盘的数据。

优化点:顺序 I/O 写日志(性能高于随机写数据页)。

7. binlog的格式有哪几种?

STATEMENT

记录原始 SQL 语句

- 优点:日志量小,性能高 - 缺点:非确定性函数(如

NOW()

)可能导致主从不一致

ROW

记录每行数据的变更细节(如修改前后的值)

- 优点:数据一致性高 - 缺点:日志量大(如全表更新)

MIXED

自动选择模式:确定性语句用 STATEMENT,非确定性语句(如

UUID()

)用 ROW

平衡性能和安全性(推荐)

8. Redis中的漏桶算法

漏桶算法通过固定速率处理请求,控制流量:

  1. 原理: 请求如水流入桶(容量固定),桶底以恒定速率漏水(处理请求)。桶满则拒绝新请求。
  2. Redis 实现: 数据结构:用 INCR 统计请求数,EXPIRE 重置桶计数。关键参数: capacity:桶容量(最大请求数)leak_rate:漏水速率(每秒处理数)。
  3. 桶满策略: 直接拒绝:返回错误(简单但体验差)。排队等待:请求入队列,桶空闲时处理(需额外维护队列)。

9. redis的持久化机制

Redis 提供两种持久化方式:

  1. RDB(快照): 原理:定时 fork 子进程生成内存数据快照(二进制文件 dump.rdb)。优点:恢复速度快,文件紧凑适合备份。缺点:可能丢失最后一次快照后的数据(默认间隔 5 分钟)。
  2. AOF(追加文件): 原理:记录每个写操作命令(文本文件),重启时重放命令恢复数据。刷盘策略: always:每次写操作刷盘(安全但性能差)everysec:每秒刷盘(默认,最多丢 1 秒数据)。
  3. 混合持久化(Redis 4.0+): AOF 文件包含 RDB 头 + 增量操作,兼顾恢复速度和数据安全。

10. redis的数据类型

String

文本、数字或二进制数据

缓存、计数器(

INCR

Hash

键值对集合(类似对象)

存储用户信息(如

user:1000 {name:"Alice"}

List

双向链表,支持有序插入

消息队列(

LPUSH

/

RPOP

Set

无序唯一集合

标签系统、共同好友(

SINTER

Sorted Set

带分数的有序集合

排行榜(

ZADD

+

ZRANGE

Stream

消息流(支持消费者组)

实时消息系统(类似 Kafka)

Geospatial

地理位置坐标

附近的人(

GEORADIUS

Bitmap/HyperLogLog

位操作/基数统计

签到(

SETBIT

)、UV 统计

11. 讲一下Go语言的垃圾回收机制

Go语言的垃圾回收(GC)采用并发标记-清除算法,结合三色标记法写屏障技术,旨在减少停顿时间(STW)并支持高并发场景。其核心机制如下:

  1. 三色标记法:白色对象:未被访问的对象(待回收)。灰色对象:已访问但引用的对象未完全扫描。黑色对象:已访问且所有引用已扫描(存活对象)。 标记阶段从根对象(全局变量、栈变量等)开始,递归遍历可达对象并标记为灰色,逐步转为黑色。
  2. 并发与并行执行:并发标记:GC线程与用户程序并发运行,通过写屏障(Write Barrier)记录对象引用变化,防止漏标。并行清除:标记完成后,清理白色对象的内存(与程序并行)。
  3. 触发条件:内存阈值:当堆内存达到上次GC后存活对象的2倍(默认GOGC=100%),自动触发。手动触发:调用runtime.GC()。系统内存压力:操作系统要求释放内存时。
  4. 分代收集优化:对象分为新生代(频繁回收)和老生代(较少回收),优先扫描新生代,减少全局遍历开销。
  5. 性能优化建议:减少堆分配:复用对象(如sync.Pool)。避免小对象频繁分配:使用数组替代切片或预分配内存。

GC对程序的影响:最大停顿时间通常控制在10ms以内,但高频分配仍可能导致延迟升高。

12. slice的扩容机制

Go中slice的扩容通过append触发,底层调用runtime.growslice函数,策略兼顾效率与内存利用率:

  1. 扩容时机:当len(slice) + 新增元素数 > cap(slice)时触发扩容。
  2. 扩容策略(Go 1.18+):容量 < 256:双倍扩容(newcap = oldcap * 2)。容量 ≥ 256:按公式newcap = oldcap + (oldcap + 3*256) / 4逐步增加(约1.25倍),避免过度浪费。特殊处理:若扩容后仍不足,直接采用所需容量。
  3. 内存对齐:计算newcap后,根据元素大小向上取整到内存页大小(如int类型按8字节对齐)。
  4. 数据迁移:分配新内存空间,拷贝旧数据到新数组,原数组由GC回收。

示例

go 体验AI代码助手 代码解读复制代码s := []int{1, 2}  
s = append(s, 3, 4)  // 原cap=2,扩容后cap=4(2*2)

优化建议:预分配容量(make([]int, 0, 100))以减少扩容开销。

13. Go 协程调度模型(GMP)是什么?

GMP是Go语言实现高并发的核心调度模型,包含三个组件:

  1. G(Goroutine):轻量级协程,初始栈2KB,由Go运行时管理。
  2. M(Machine):操作系统线程(内核线程),负责执行G的代码。
  3. P(Processor):逻辑处理器,维护本地G队列(runq),数量默认为CPU核心数(可通过GOMAXPROCS调整)。

工作流程

  • G创建go func()将G加入当前P的本地队列;若队列满,则转移一半G到全局队列。
  • M绑定P:M需绑定P才能执行G,从P的本地队列获取G;若本地队列空,则: 从全局队列获取一批G。从其他P的队列窃取(Work Stealing) 一半G。
  • 阻塞处理: 系统调用:M解绑P,P被其他M接管继续执行G。恢复后:M尝试绑定空闲P执行原G,否则G加入全局队列,M休眠。

优势

  • 高并发:百万级Goroutine可被少量M调度。
  • 低延迟:协作式调度 + 抢占机制(基于信号)减少长任务阻塞。

14. Channel 的底层实现和阻塞机制是怎样的?

Channel的底层结构为hchan(源码定义),核心机制如下:

go 体验AI代码助手 代码解读复制代码type hchan struct {
    buf      unsafe.Pointer // 环形缓冲区
    qcount   uint           // 当前缓冲区元素数
    dataqsiz uint           // 缓冲区大小
    lock     mutex          // 互斥锁
    sendq    waitq          // 发送等待队列(sudog链表)
    recvq    waitq          // 接收等待队列(sudog链表)
}

  1. 阻塞条件:发送阻塞:无缓冲Channel无接收者,或缓冲Channel缓冲区满(qcount == dataqsiz)。接收阻塞:无缓冲Channel无发送者,或缓冲Channel缓冲区空(qcount == 0)。
  2. 阻塞处理:阻塞的G被封装为sudog加入sendq或recvq队列,M切出执行其他G。当条件满足时(如新数据到达),唤醒队列中第一个等待的G(FIFO顺序)。
  3. 直传优化:若发送时recvq非空,数据直接拷贝给等待的接收者,避免经过缓冲区。

示例

go 体验AI代码助手 代码解读复制代码ch := make(chan int, 2)
ch <- 1  // 写入缓冲区
ch <- 2  // 缓冲区满,再次写入会阻塞

15. defer 关键字的执行顺序

defer延迟执行函数,规则如下:

  1. 执行顺序:多个defer按后进先出(LIFO) 顺序执行(类似栈)。
  2. 参数求值时机:defer的参数在声明时立即求值,而非执行时。
  3. 执行时机:在函数返回前执行(包括return赋值后、函数结束前),即使发生panic也会执行。
  4. 常见陷阱:循环中的defer:若在循环内使用defer,可能因延迟执行导致资源未及时释放(如文件句柄)。建议改用匿名函数包裹。返回值修改:若defer修改命名的返回值,会影响最终结果。

应用场景:资源释放(文件关闭)、错误恢复(recover)等。

16. 说下TCP和UDP的区别

TCP与UDP是传输层协议的核心区别在于可靠性与连接机制

连接性

面向连接(三次握手)

无连接

可靠性

可靠(确认重传、有序)

不可靠(可能丢包、乱序)

数据格式

字节流(无边界)

数据报(有边界)

头部开销

较大(20-60字节)

较小(8字节)

速度

慢(拥塞控制、握手开销)

快(无控制开销)

应用场景

文件传输、HTTP、邮件

视频流、DNS、实时游戏

关键差异解释

  • 有序性:TCP通过序列号保证数据顺序;UDP不保证。
  • 流量控制:TCP使用滑动窗口;UDP无控制机制。
  • 适用性:TCP适合需高可靠性的场景;UDP适合低延迟容忍丢包的场景。

17. TCP具体采用了哪些机制来保证其可靠性

TCP通过以下6大机制确保数据传输可靠:

  1. 序列号与确认应答(ACK):每个数据包分配唯一序列号,接收方返回ACK确认收到数据(累积确认)。
  2. 超时重传:发送方启动定时器(RTO动态计算),未收到ACK则重传数据。
  3. 流量控制(滑动窗口):接收方通过Window字段告知剩余缓冲区大小,发送方据此调整发送速率(避免淹没接收方)。
  4. 拥塞控制:慢启动:初始窗口小,每RTT翻倍。拥塞避免:窗口达到阈值后线性增长。快重传/快恢复:收到3个重复ACK立即重传,避免等待超时。
  5. 校验和:16位校验和验证数据完整性,错误则丢弃包并触发重传。
  6. 连接管理:三次握手:建立可靠连接(同步序列号)。四次挥手:确保双方数据发送完成后再关闭连接。

总结:TCP通过上述机制实现无丢失、无重复、无错误、有序的数据传输。

18. HTTP协议的不同版本对比

HTTP/1.0

基础版本

短连接(每次请求新建TCP)、无Host头、无管道化

HTTP/1.1

解决1.0性能瓶颈

持久连接(Keep-Alive)、Host头(支持虚拟主机)、管道化(但队头阻塞未解决)

HTTP/2

性能优化

二进制分帧、头部压缩(HPACK)、多路复用(解决队头阻塞)、服务器推送

HTTP/3

基于QUIC协议(UDP)

0-RTT快速连接、传输层多路复用(彻底解决队头阻塞)、内置TLS 1.3加密

关键演进

  • HTTP/1.1 → HTTP/2:从文本到二进制协议,多路复用提升并发效率。
  • HTTP/2 → HTTP/3:从TCP到QUIC(UDP),避免传输层队头阻塞,更适合高丢包网络。

记忆口诀

HTTP/1.1:持久连接省握手,Host区分虚拟节点。

HTTP/2:二部曲(二进制、头部压缩、乱序传输)。

19. 操作系统中的进程调度算法

操作系统的进程调度算法旨在高效分配CPU资源,核心算法包括:

  1. 先来先服务(FCFS):按就绪队列顺序执行,非抢占式。缺点:长任务阻塞短任务("护航效应")。
  2. 短作业优先(SJF):优先执行预估运行时间短的进程。缺点:长任务可能饥饿。
  3. 轮转法(Round Robin, RR):每个进程分配固定时间片(如10ms),超时后放回队列尾部。优点:公平性强,适合分时系统。
  4. 优先级调度:静态/动态优先级(如高响应比优先:优先级 = (等待时间 + 执行时间) / 执行时间)。缺点:低优先级进程可能饥饿。
  5. 多级反馈队列(MLFQ):多队列(优先级递减 + 时间片递增),新进程加入最高优先级队列。优势:平衡响应时间与吞吐量,结合RR与优先级优点。

评价指标:吞吐量、周转时间、响应时间、CPU利用率。

20. 用户态和内核态之间的区别

用户态和内核态是CPU特权级的两种模式,核心区别如下:

特权级别

Ring 3(低特权)

Ring 0(高特权)

内存访问

仅限用户空间(不可访问内核内存)

可访问全部内存空间

指令权限

禁止执行特权指令(如I/O操作、中断管理)

可执行所有指令

稳定性

进程崩溃不影响系统

内核崩溃导致系统宕机

性能开销

常规代码执行

系统调用需上下文切换(约1μs~10μs开销)

切换方式

  • 用户态 → 内核态:通过系统调用(如read())、中断或异常触发。
  • 内核态 → 用户态:系统调用返回前恢复用户态上下文。

示例

c 体验AI代码助手 代码解读复制代码read(file_fd, buffer, size);  // 系统调用,触发切换至内核态

意义:隔离用户程序与内核,防止恶意操作破坏系统稳定性。

21. 怎么从用户态切换到内核态

用户态切换到内核态主要通过以下三种方式触发,核心机制是CPU特权级的转换(从Ring 3切换到Ring 0)和上下文保存

  1. 系统调用(主动触发)原理:用户进程通过调用操作系统提供的接口(如read()、write())主动请求内核服务。步骤: ① 用户程序将系统调用号存入寄存器(如rax),参数存入rdi、rsi等寄存器。 ② 执行syscall或int 80h指令,触发软中断,CPU切换到内核态(Ring 0)。 ③ 内核保存用户态上下文(RIP、RSP、RFLAGS等寄存器值)到内核栈,跳转至中断处理程序。
  2. 异常(被动触发)原理:用户程序执行时发生不可预知的错误(如除零、缺页异常),CPU自动切换至内核态处理。示例: 缺页异常:进程访问未分配的内存页,触发内核分配物理页并更新页表。处理流程:保存用户态上下文→执行异常处理程序→修复后返回用户态(若可恢复)。
  3. 中断(被动触发)原理:外部设备(如磁盘、网卡)完成任务后发送中断信号,强制CPU暂停当前指令并处理中断。流程: 设备中断触发,CPU保存用户态上下文,切换到内核态执行中断处理程序(如磁盘I/O完成后的回调)。中断处理结束,通过iret指令恢复用户态上下文。

切换的底层步骤

  1. 从进程描述符中获取内核栈指针(ss0esp0)。
  2. 将用户态寄存器状态(CS、EIP、EFLAGS等)压入内核栈。
  3. 加载中断处理程序的入口地址到寄存器,执行内核代码。

关键点

  • 系统调用是主动切换,异常和中断是被动切换
  • 切换开销:上下文保存与恢复耗时约1μs~10μs,频繁切换影响性能。

22. 进程之间的通信方式

进程间通信(IPC)主要用于数据传输、资源共享或事件通知,分为以下五类:

管道(Pipe)

单向数据流,基于内核缓冲区,匿名管道仅用于父子进程,命名管道(FIFO)支持无关进程。

命令行工具链(如

ls | grep

消息队列

内核管理的消息链表,进程通过唯一标识符读写消息,支持异步通信。

解耦生产者与消费者(如日志系统)

共享内存

多个进程映射同一块物理内存,直接读写数据,需配合同步机制(如信号量)。

高性能数据共享(如大型矩阵计算)

信号量

计数器,控制多进程对共享资源的访问(P/V操作),解决互斥与同步问题。

资源池管理(如数据库连接池)

套接字(Socket)

跨网络通信,支持TCP/UDP协议,适用于分布式系统。

客户端-服务器模型(如Web请求)

对比与选择

  • 性能:共享内存 > 消息队列 > 管道 > 套接字(本地通信)。
  • 复杂度:套接字 > 共享内存 > 消息队列 > 管道。
  • 建议: 父子进程协作:匿名管道。无关进程通信:命名管道或消息队列。高频数据交换:共享内存+信号量。

23. 进程之间同步的方式有哪些

进程同步解决资源竞争与执行顺序问题,核心机制如下:

  1. 信号量(Semaphore)原理:整数计数器,通过P()(等待)和V()(通知)操作控制资源访问。类型: 二进制信号量:值0/1,实现互斥锁。计数信号量:限制资源数量(如线程池)。
  2. 互斥锁(Mutex)原理:二值锁,同一时间仅一个进程持有锁,其他进程阻塞等待。场景:保护临界区(如共享文件写入)。
  3. 条件变量(Condition Variable)原理:与互斥锁配合使用,当条件不满足时阻塞进程,条件达成时唤醒(如pthread_cond_wait)。示例:生产者-消费者模型,缓冲区空时消费者等待。
  4. 读写锁(Read-Write Lock)原理:允许多个读操作并发,写操作独占资源。场景:读多写少(如数据库查询)。
  5. 屏障(Barrier)原理:多个进程到达屏障点后同时继续执行,用于并行计算同步。

同步问题的本质

  • 互斥:确保资源不被同时访问(如打印机使用)。
  • 同步:协调进程执行顺序(如A进程输出后B进程才能处理)。

24. 介绍一下单例模式

单例模式确保一个类仅有一个实例,并提供全局访问点,常用于资源管理(如配置、线程池)。

实现方式

  1. 饿汉式:类加载时创建实例,线程安全但可能浪费内存。
  2. 懒汉式(双重检查锁):首次调用时创建实例,避免资源浪费。

特点

  • 优点:避免重复创建,节省内存;统一访问入口。
  • 缺点:需处理多线程安全问题;可能隐藏代码依赖关系。

应用场景

  • 数据库连接池(避免多次初始化连接)。
  • 日志管理器(全局唯一写入点)。

25. 策略模式

策略模式定义一组算法,封装每个算法使其可互换,让算法独立于客户端变化。

核心组件

  1. 策略接口(Strategy):声明算法方法(如execute())。
  2. 具体策略类(ConcreteStrategy):实现不同算法(如支付宝支付、微信支付)。
  3. 上下文类(Context):持有策略引用,调用策略方法。

示例:支付系统

java 体验AI代码助手 代码解读复制代码interface PaymentStrategy { void pay(int amount); }  
class AlipayStrategy implements PaymentStrategy {  
    public void pay(int amount) { /* 支付宝支付逻辑 */ }  
}  
class WeChatPayStrategy implements PaymentStrategy {  
    public void pay(int amount) { /* 微信支付逻辑 */ }  
}  
class ShoppingCart {  
    private PaymentStrategy strategy;  
    public void setStrategy(PaymentStrategy strategy) { this.strategy = strategy; }  
    public void checkout(int amount) { strategy.pay(amount); }  
}  

优势

  • 灵活扩展:新增支付方式无需修改上下文。
  • 解耦:算法与客户端分离,避免条件分支(如if-else)。

适用场景

  • 支付方式、排序算法等需动态切换的场景。
  • 算法需独立测试或复用。

26. 图的遍历算法有哪些,并简要说明它们的特点

图的遍历分为两类,特点对比如下:

深度优先搜索(DFS)

栈(递归)

深度优先,一条路径到底

可能陷入深分支,空间复杂度O(V)(顶点数)

拓扑排序、连通性检测

广度优先搜索(BFS)

队列

层次优先,按距离扩展

可求最短路径(无权图),空间复杂度O(V)

最短路径、社交网络关系

关键差异

  • 路径探索:DFS适合探索所有可能路径(如迷宫求解),BFS适合最短路径(如社交关系链)。
  • 复杂度:时间复杂度均为O(V+E)(V为顶点数,E为边数),但BFS空间开销可能更大(队列存储)。

27. 介绍图的广度优先算法

广度优先搜索(BFS)按层次遍历图,核心是队列管理层级扩散,确保先访问的节点其邻接点优先访问。

算法流程

  1. 初始化: 将起始节点标记为已访问,加入队列。
  2. 迭代访问: 队首节点出队,访问其所有未访问邻接节点,标记并入队。重复直至队列为空。

特点

  • 最短路径:在无权图中,BFS首次访问到目标节点的路径一定是最短路径。
  • 层级性:队列中节点按距离起始点的层级排序。

应用场景

  • 网络爬虫(按链接深度抓取)。
  • 社交网络好友推荐(N度关系)。

性能优化:稀疏图使用邻接表存储,避免邻接矩阵的O(V²)遍历开销。

全部评论

(3) 回帖
加载中...
话题 回帖

近期热帖

热门推荐