@timeout 注解仅作用于单个测试方法，不支持类级别声明，也无法强制限定全局测试生命周期；其超时基于线程中断机制，对非响应中断的cpu密集型操作无效。
@Timeout 注解在 JUnit 中用于为单个测试方法设置超时时间，但它不支持类级别声明，也不能用于“强制限定全局测试用例的生命周期”。这是常见的误解。下面分清楚几个关键点：
✅ @Timeout 只作用于单个测试方法
JUnit 5（junit-jupiter）中的 @Timeout 是方法级注解，必须写在 @Test 方法上，不能标注在测试类上。例如：
-
@Timeout(value = 500, unit = TimeUnit.MILLISECONDS)表示该测试方法最多运行 500 毫秒，超时则自动失败 - 若放在类上（如
@Timeout(1000)），编译会通过但**完全无效**——JUnit 不识别类级别的@Timeout
❌ 没有“全局生命周期控制”的内置机制
JUnit 本身不提供“为整个测试类或整个测试套件统一设超时”的能力。所谓“全局”，需手动实现：
- 可借助
@BeforeEach+ 计时器字段 +@AfterEach校验，但无法中断已卡住的线程（Java 线程不可强制终止） - 更可靠的做法是：将耗时操作封装进
ExecutorService并配合Future.get(timeout, unit)显式控制 - 若想约束整套测试（如 Maven 构建中所有测试总时长），应使用构建工具配置，例如 Maven Surefire 的
<forkedprocesstimeoutinseconds></forkedprocesstimeoutinseconds>
⚠️ 注意线程安全与中断语义
@Timeout 背后依赖 Thread.interrupt()，但仅对响应中断的阻塞操作（如 Thread.sleep、Object.wait、NIO 通道读写）有效：
- 纯 CPU 密集型循环（如
while(true) { i++; }）不会被中断，超时后测试仍会挂起，直到 JVM 强制终止进程（取决于 runner） - 建议在业务逻辑中主动检查
Thread.currentThread().isInterrupted()并及时退出
? 替代方案：统一超时基类（伪“类级”效果）
虽不能真正类级生效，但可通过抽象基类 + 模板方法模拟统一超时策略：
- 定义
abstract class TimeoutTestBase，含@BeforeEach启动计时、@AfterEach断言耗时 - 子类复写
protected abstract void doTest() throws Exception，并在@Test中调用它 - 注意：这只能事后断言，不能中断正在执行的代码 —— 和
@Timeout的“强制中断”有本质区别
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
