为何Matcher.find()返回true后调用m.start()仍抛出No successful match so far异常？

问题代码 #

Matcher m = patternFoo.matcher(sFoo);

if(m.find()){
    ...
    m.start()
    ...
}

异常信息 #

Exception: No successful match so far
Class: java.lang.IllegalStateException
 Stack trace: java.lang.IllegalStateException: No successful match so far
        at java.util.regex.Matcher.ensureMatch(Matcher.java:1116)
        at java.util.regex.Matcher.start(Matcher.java:1158)
        at java.util.regex.Matcher.start(Matcher.java:1130)

补充背景 #

• m为单线程访问的局部变量
• 问题在数十万量级的APP中偶现
• 怀疑与APP中频发的OutOfMemory（编解码器导致）有关

核心原因推测 #

从JDK源码逻辑来看，Matcher.start()会先调用ensureMatch()校验匹配状态，仅当内部记录匹配起始位置的first字段小于0时，才会抛出该异常。而find()返回true的前提是已经成功找到匹配，理论上first应该被正确赋值为有效位置。

结合偶现特性和OOM背景，最可能的触发原因是堆内存损坏：当APP因编解码器操作引发OOM时，JVM内存管理可能出现异常，导致Matcher对象内部的状态变量（如first、last）被意外篡改。即便find()执行时成功设置了匹配状态，后续调用m.start()前，内存中的这些字段已被破坏为未匹配状态（比如first被改为-1），最终触发异常。

编解码器场景下的OOM往往伴随大量内存分配/释放操作，更容易引发堆内存数据错乱，这种情况下局部变量的内存区域也可能受到波及。

解决方向 #

1. 内存问题根因排查：重点监控编解码器相关的资源使用，排查是否存在内存泄漏或过度分配情况，比如图片、视频编解码后未及时释放缓冲区、解码器实例等资源。
2. 增加防御性校验：在调用m.start()前补充二次状态校验，避免内存异常导致的状态失效：

   Matcher m = patternFoo.matcher(sFoo);
   if(m.find()){
       ...
       // 二次校验匹配状态
       if(m.start() != -1){
           // 执行后续逻辑
       }
       ...
   }
   

   或者在find()后立即获取并保存start值，避免后续状态被破坏：

   Matcher m = patternFoo.matcher(sFoo);
   if(m.find()){
       int matchStart = m.start();
       // 直接使用matchStart，而非后续再次调用m.start()
       ...
   }
   

3. 特定环境兼容性排查：如果问题集中在特定机型或Android版本，检查是否存在ART虚拟机在OOM场景下的内存管理bug，针对性做版本适配处理。

内容的提问来源于stack exchange，提问作者Hong