Day11

1. HTTP常见状态码有哪些？

1. 1xx 类状态码属于提示信息，是协议处理中的一种中间状态，实际用的比较少。
2. 2xx 类状态码表示服务器成功处理了客户端的请求。
3. 3xx 类状态码表示客户端请求的资源发生了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。
4. 4xx 类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。
5. 5xx 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。

常见：

• 200：请求成功
• 301：永久重定向；302：临时重定向
• 404：无法找到此页面；405：请求的方法类型不支持
• 500：服务器内部出错

2. MySQL事务特性是什么？怎么实现的？

1. 原子性（Atomicity）：事务中的所有操作要么全部完成，要么全部回滚。
2. 一致性（Consistency）：事务前后，数据处于一致状态（满足约束条件）。
3. 隔离性（Isolation）：并发事务之间互不干扰，每个事务都想自己在独立执行。
4. 持久性（Durability）：一旦事务提交，修改就会永久保存，即使系统宕机也能恢复。

---

• 原子性通过 Undo Log（回滚日志）实现：每执行一条 DML （增删改）语句，InnoDB 会将数据变更前的状态写入 Undo Log，如果事务失败或调用了 ROLLBACK，InnoDB 就会根据 Undo Log 进行回滚。
• 一致性依靠原子性 + 隔离性 + 约束：回滚保证事务要么成功要么失败，隔离性避免脏读，外键、唯一约束等在事务开始前就要满足。
• 隔离性通过 MVCC（多版本并发控制）和锁机制实现：支持四种隔离级别，通过 MVCC（快照读）实现读操作并发不加锁，保证效率；加锁机制保证写操作不冲突，如行锁、间隙锁、意向锁等。
• 持久性通过 Redo Log（重做日志）：当事务提交时，修改数据的操作会写入 Redo Log，如果数据库宕机，在重启时可以用过 Redo Log 恢复未同步的数据页，确保事务持久性。

3. Java线程池的核心参数有哪些？

线程池是为了减少频繁的创建线程和销毁线程带来的性能损耗，原理如下图：

当我们提交任务时，线程池会优先使用核心线程处理任务；如果核心线程已满，则尝试将任务放入任务队列中；若队列也满了，则判断是否还能创建非核心线程（总线程数未达到最大值），若可以就创建新线程处理任务；如果线程数已达到最大，任务将根据设置的拒绝策略进行处理（如抛异常、丢弃、调用者执行等）。执行完的线程不会立即销毁，而是等待一定时间以复用，非核心线程若长时间空闲会被回收，从而实现高效的线程管理和资源利用。

new ThreadPoolExecutor()的七个参数：

组成	作用
corePoolSize	核心线程数，线程池初始化后保持不被回收的线程数
maximumPoolSize	最大线程数，队列满了后允许创建的最大线程数
workQueue	任务阻塞队列（如 LinkedBlockingQueue）
threadFactory	线程创建工厂，决定线程命名、优先级等
handler	拒绝策略，当线程池无法处理新任务时的处理方式
keepAliveTime	非核心线程空闲多久会被回收
unit	keepAliveTime 时间的单位

4. 数据库翻页（limit）查询时，发现越往后查询越来越慢，为什么？该如何修改SQL能解决？

例如SQL：

SELECT * FROM user ORDER BY id LIMIT 100000, 10;

MySQL 会先扫描前面 100000 条数据，然后丢弃这些数据，再返回第 100001 到 100010 条。这就导致随着 offset 增大，扫描的数据越来越多；性能逐渐下降，慢在“跳过”的那一部分数据上；特别是是数据量大时，响应时间可能成倍增长。

方案一：使用主键或唯一索引做“位置标记”分页，基于上一次的最大 ID 做分页，而不是 OFFSET 跳页。

• 优化后（假设上一页最后一条记录id是100000）
  SELECT * FROM user WHERE id > 100000 ORDER BY id LIMIT 10;
  扫描和返回的是精确的 10 条；性能稳定，不随着页数增大而下降；非常适合大数据量的“滚动加载”或“上一页/下一页”式分页。

方案二：覆盖索引 + 子查询定位 ID。

• 用子查询先取 ID（走索引），再回表查数据
  SELECT * FROM user WHERE id IN (SELECT id FROM user ORDER BY id LIMIT 100000, 10);
  适用于无法用主键分页的情况。

5. Insert或Update，不用两个语句去分别判断，用一条语句实现存在就更新，否则就插入？

最常用方式：INSERT ... ON DUPLICATE KEY UPDATE
适用于主键或唯一索引冲突时进行更新。

INSERT INTO 表名 (字段1, 字段2, ...)
VALUES (值1, 值2, ...)
ON DUPLICATE KEY UPDATE 字段1=新值1, 字段2=新值2;

6. DNS基于什么协议实现的？

基于 UDP 协议

1. 客户端发起 DNS 请求：客户端向本地 DNS 服务器请求解析 www.server.com，使用 UDP，端口 53。
2. 本地 DNS 服务器向根域名服务器查询：本地 DNS 发现自己没有www.server.com的记录，于是向根域名服务器请求（UDP 查询）。
3. 根服务器响应（返回.com顶级域服务器地址）：根服务器并不直接返回 IP，而是告诉你：“这是 .com 的事，你去问 .com 的 DNS。”
4. 继续迭代查询：本地 DNS 接着去问 com顶级域服务器：www.server.com是谁？.com顶级域返回一个 权威DNS 服务器地址（比如 ns1.server.com）。
5. 向权威 DNS 服务器询问具体 IP：本地 DNS 向server.com域的权威服务器发起请求：www.server.com到底啥 IP？权威服务器终于返回了最终的 IP 地址，比如：X.X.X.X。
6. 本地 DNS 将 IP 返回客户端，客户端就可以访问了。

名称	英文	作用	举例
1. 本地 DNS 服务器	Local DNS Resolver	最先被问，查缓存	运营商 DNS，如 114.114.114.114
2. 根 DNS 服务器	Root DNS Server	告诉你“顶级域（TLD）”服务器位置	管理 .com、.cn 等
3. 顶级域名服务器	TLD DNS Server	告诉你权威服务器位置	比如负责 .com 的服务器
4. 权威 DNS 服务器	Authoritative DNS Server	最终返回目标 IP 地址	比如负责 server.com 的服务器

7. 为什么是UDP？

因为基于 UDP 实现 DNS 能够提供低延迟、简单快速、轻量级的特性，更适合 DNS 这种需要快速响应的域名解析服务。

1. 低延迟：UDP 是一种无连接的协议，不需要在数据传输前建立连接，因此可以减少传输时延，适合 DNS 这种需要快速响应的应用场景。
2. 简单快速：UDP 相比于 TCP 更简单，没有 TCP 的连接管理和流量控制机制，传输效率更高，适合 DNS 这种快速传输数据的场景。
3. 轻量级：UDP 头部较小，占用较少的网络资源，对于小型请求和响应来说更加轻量级，适合 DNS 这种频繁且短小的数据交换。

8. http的特点是什么？

HTTP 是一种基于文本的应用层协议，通信内容都是人类可读的文本格式，便于开发和调试；它具有良好的可扩展性，支持自定义头部和方法，使得协议可以不断适应新的需求；HTTP 还非常灵活，能够传输各种类型的数据（如 HTML、JSON、图片等），适用于 Web、API 等多种场景；不过它是无状态的，也就是说每次请求之间没有记忆，服务器不会自动记住客户端的信息，因此需要依靠 Cookie 或 Session 等机制来维持用户会话状态。

9. http无状态体现在哪？

HTTP 是一种无状态协议，它的无状态体现在每一次请求都是完全独立的，服务器不会自动记录客户端的历史信息或状态。也就是说，服务器在处理每一个请求时，不会记得之前你做过什么，也无法判断当前请求是否来自同一个用户。
为了弥补这种无状态的特性，实际开发中通常会借助 Cookie、Session 或 Token 等机制来维护用户状态。其中 Cookie 是通过在响应中写入一个「小纸条」交给客户端保管，客户端每次发起请求时再自动携带这个「纸条」回来，让服务器“认出”这是哪个用户。这样，虽然 HTTP 本身是无状态的，但我们可以用这些机制人为地“构造状态”，实现登录态保持、购物车等功能。

10. Cookie和Session的区别

Cookie 和 Session 都是用来实现用户状态保持（会话管理）的机制，区别如下：

1. 存储位置不同：Cookie 存储在客户端浏览器中，Session 存储在服务器端。
2. 安全性：Cookie 暴露在客户端，容易被窃取或篡改（如XSS），Session 在服务器中更安全，不容易被盗。
3. 占用资源：Cookie 占用客户端资源（一般每个站点最多存 20 个，每个大小约 4 KB），Session 占用服务器内存，如果用户多了，服务器压力会增大。
4. 生命周期：Cookie 可以设置较长时间保存，Session 一般只在浏览器关闭或超时后失效。
5. 工作原理：用户第一次访问时，服务器创建一个 Session 并生成唯一 ID，这个 Session ID 会通过 Cookie 自动发送给客户端，之后每次请求，浏览器都带着这个 Cookie（里面是 Session ID），服务器就用这个 ID 找回用户信息。
6. 使用场景：Cookie：适合做“记住我”功能，客户端存储简单信息，比如用户名。Session：适合保存敏感信息，比如用户登录状态、权限等。