小菜鸟

单元测试中数据库数据未更新的问题解析：自动回滚机制与解决方案

在进行单元测试（尤其是涉及数据库操作的测试）时，常遇到 “测试执行成功但数据库数据未变化” 的现象。这通常与测试框架的事务自动回滚机制有关，本文将解析其原理并提供解决方案。

问题根源：测试框架的自动回滚机制

主流的 Java 测试框架（如 Spring Test）为了避免测试数据污染数据库，默认会对测试方法中的数据库操作进行自动回滚。其核心逻辑是：

1. 测试方法执行前，框架开启一个事务；
2. 测试方法中的数据库操作（如插入、更新）在该事务中执行；
3. 测试方法执行成功后，框架自动回滚事务，所有操作不提交到数据库；
4. 若测试失败，同样会回滚事务，保证数据库状态不受影响。

这一机制的优点是隔离测试数据，避免多次测试之间的相互干扰，但也会导致 “测试成功却看不到数据变化” 的现象。

解决方案：禁用自动回滚

若需要在测试后保留数据库数据（如验证数据正确性、调试测试逻辑），可通过以下方式禁用自动回滚：

使用 @Rollback 注解（Spring Test）

在测试方法或测试类上添加 @Rollback(false)，显式关闭自动回滚：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

import org.springframework.test.annotation.Rollback;
import org.springframework.test.context.junit4.SpringRunner;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.transaction.annotation.Transactional;

@RunWith(SpringRunner.class)
@Transactional // 开启事务（默认会回滚）
public class UserDaoTest {

    @Test
    @Rollback(false) // 禁用自动回滚，测试完成后提交事务
    public void testInsertUser() {
        // 数据库插入操作（如 userDao.insert(new User("test"))）
        // 测试成功后，数据会保留在数据库中
    }
}

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 分发处理

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 跟踪令牌状态，确保每个表单请求仅被处理一次。

实现步骤：

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 对象后执行更新