小菜鸟

POST 请求体无法重复读取的原因与解决方案

在 Java Web 开发中，经常会遇到 “POST 请求体只能读取一次” 的问题：当过滤器（Filter）读取请求体后，Servlet 中再次读取时会返回空数据。这一现象与请求流的底层实现密切相关，本文将解析其原因，并提供基于请求包装类的解决方案。

为什么 POST 请求体无法重复读取？

POST 请求体的内容通过输入流（ServletInputStream）读取，而输入流具有一次性读取的特性，核心原因如下：

1. 输入流的 “消费性”

输入流（如 CoyoteInputStream，Tomcat 的实现）本质上是对底层字节流的封装，其读取过程是 “消费性” 的：

• 读取数据时，流的指针会向后移动；
• 当流读取完毕（指针到达末尾），再次读取会返回 -1（表示已读完）；
• 流关闭后（如 close() 被调用），无法再次打开或重置。

2. Tomcat 中的具体实现

以 Tomcat 为例，getInputStream() 返回的 CoyoteInputStream 内部依赖 InputBuffer 存储请求体数据。当数据被读取后，InputBuffer 中的缓存会被清空，且流的 closed 状态会被标记为 true：

1
2
3
4
5
6
7
8
9
10
11
12
13

// Tomcat 的 CoyoteInputStream 部分源码
public int read(byte[] b, int off, int len) throws IOException {
    if (closed) { // 若流已关闭，直接抛出异常
        throw new IOException("Stream closed");
    }
    if (checkByteBufferEof()) { // 若数据已读完，返回 -1
        return -1;
    }
    // 读取剩余数据并移动指针
    int n = Math.min(len, bb.remaining());
    bb.get(b, off, n);
    return n;
}

Java Web 表单重复提交问题：原因分析与解决方案

表单重复提交是 Web 开发中常见的问题，可能导致数据重复入库、订单重复创建等严重后果。本文将详细分析重复提交的场景、成因，并提供基于 Session 的解决方案，确保表单数据仅被处理一次。

表单重复提交的常见场景

1. 场景一：提交后刷新响应页面

• 操作流程：用户提交表单 → 服务器通过 request.getRequestDispatcher().forward() 转发到结果页 → 用户刷新结果页。
• 原因：刷新时浏览器会重新发送最后一次请求（即表单提交请求），而地址栏仍显示 Servlet 路径，导致重复提交。

2. 场景二：快速重复点击提交按钮

• 操作流程：用户在短时间内多次点击 “提交” 按钮。
• 原因：服务器尚未处理完第一次请求，第二次请求已到达，导致重复处理。

3. 场景三：后退后再次提交

• 操作流程：用户提交表单 → 点击浏览器 “后退” 按钮 → 再次点击 “提交” 按钮。
• 原因：后退后表单数据仍保存在浏览器中，再次提交会重新发送相同请求。

注意：不属于重复提交的情况

点击 “后退”→ 刷新页面 → 再次提交，不属于重复提交。因为刷新页面会重新加载表单页，此时提交的是新的请求（原表单数据可能已清空或重新生成）。

解决方案：基于 Session 的令牌验证机制

核心思路是生成唯一令牌（Token），通过 Session 跟踪令牌状态，确保每个表单请求仅被处理一次。

实现步骤：

Java Web 中多个请求共享同一个 Servlet 的实现方案

在 Java Web 开发中，多个请求共用同一个 Servlet 是常见需求（如一个模块的增删改查操作）。这种方式可避免创建过多 Servlet 类，简化代码结构。本文将详细介绍两种主流实现方案：基于请求参数的方法分发和基于 URL 路径的反射调用。

方案一：基于请求参数的方法分发

通过在 URL 中添加 method 参数（如 ?method=add 或 ?method=delete），在 Servlet 中根据参数值分发到不同处理方法。

实现步骤：

1. 前端请求携带 method 参数

1
2
3
4
5
6
7
8

<!-- 列表页面 -->
<a href="/user?method=list">用户列表</a>
<!-- 添加页面 -->
<a href="/user?method=toAdd">添加用户</a>
<!-- 表单提交 -->
<form action="/user?method=save" method="post">
    <!-- 表单内容 -->
</form>

1. Servlet 中根据 method 分发处理

Java Web 中文乱码问题全解析：GET/POST 请求编码解决方案

中文乱码是 Java Web 开发中常见的问题，根源在于请求参数编码与解码方式不匹配。GET 和 POST 请求的参数传递方式不同，乱码原因和解决方案也存在差异。本文将详细分析中文乱码的成因，并提供针对性的解决方法，覆盖 Tomcat 配置、代码处理等多种场景。

中文乱码的本质原因

HTTP 协议默认使用 ISO-8859-1 编码（不支持中文），若客户端发送的中文参数使用 UTF-8 编码，而服务器端用 ISO-8859-1 解码，就会导致乱码（表现为 ??? 或一串无意义字符）。

• GET 请求：参数附加在 URL 中，编码由服务器的 URI 编码配置决定；
• POST 请求：参数放在请求体中，编码由 Content-Type 头的 charset 指定，若未指定则默认使用 ISO-8859-1。

GET 请求中文乱码解决方案

GET 请求参数通过 URL 传递，其编码处理依赖服务器配置（如 Tomcat 的 URI 编码设置），常见解决方案如下：

方案一：修改 Tomcat 配置（推荐）

在 Tomcat 的 conf/server.xml 中，为 Connector 节点添加 URIEncoding="UTF-8" 属性，强制服务器对 URI 中的参数使用 UTF-8 解码：

1
2
3
4

<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443"
           URIEncoding="UTF-8" /> <!-- 添加此行 -->

• 作用：所有 GET 请求的 URL 参数均使用 UTF-8 解码，一劳永逸解决乱码；
• 适用场景：有权限修改服务器配置的环境（如开发、测试环境）。

方案二：使用请求体编码同步 URI 编码

若无法修改 Tomcat 配置，可在 Connector 中添加 useBodyEncodingForURI="true"，使 URI 编码与请求体编码保持一致：

Hibernate NonUniqueObjectException 异常深度解析：原因、解决方案与最佳实践

org.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session 是 Hibernate 开发中常见的缓存与对象状态冲突异常，核心原因是同一 Session 的一级缓存中，存在两个 OID（主键）相同但内存地址不同的持久化对象，导致 Hibernate 无法判断哪个对象的状态应同步到数据库。本文将从异常根源、复现场景、解决方案及预防措施四个维度，彻底解决该异常。

异常核心原因：Session 缓存的 OID 唯一性约束

Hibernate 一级缓存（Session 缓存）有一个核心规则：同一 Session 中，数据库表的每条记录（对应唯一 OID）只能对应一个持久化对象实例。

当出现以下情况时，会触发该异常：

1. Session 缓存中已存在 OID 为 X 的对象 A（持久化状态）；
2. 程序试图将另一个 OID 也为 X 的对象 B（可能是游离状态或新创建的对象）纳入该 Session 管理（如执行 update()、saveOrUpdate()、merge() 等操作）；
3. Hibernate 检测到 A 和 B 的 OID 相同但内存地址不同，无法确定以哪个对象的状态同步数据库，从而抛出 NonUniqueObjectException。

异常复现场景：常见触发案例

通过具体代码场景复现异常，帮助理解问题本质。

场景 1：重复加载同一 OID 对象后执行更新