博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
pattern匹配和不匹配执行效率天差地别,JAVA的正则表达式慎用
阅读量:2790 次
发布时间:2019-05-13

本文共 868 字,大约阅读时间需要 2 分钟。

需求:给定文件命名格式,给定目录,列出其下所有满足格式的文件。格式:YYYYMMDD_单号_USER_XXXX.xlsx

为了做到通用性,计划用正则表达式去匹配。

 
^2[0-9]{7}_(.*){1,}_USER_[0-9]{4}.(xls|xlsx)$

目录下都满足条件还好,很快匹配上了。

 
20200512_0011_USER_0001.xls20200512_0011_USER_0002.xls20200512_0011_USER_0003.xls

但是运行一段时间,发现应用卡住半小时才执行完文件名匹配任务。

发现目录下还有其他文件,为啥会这么耗时呢?

sysout测试一下,发现条件不匹配正则表达式时,程序卡住不动了!!

顺便推荐个插件:devutils

base64编解码,Regex匹配,DigestUtil各种MD5/sha算法加密,URLCodec,socketClient,socketServer创建等

再也不用各种在线转换了!

System.out.println("20200530_m-12321300111M-123_PROD_0001.xlsx"    .matches("^2[0-9]{7}_(.*){1,}_USER_[0-9]{4}.(xls|xlsx)$"));

还在这卡着呢!!

网上搜了半天,有人说正则表达式的效率较低,但是不用正则还有什么办法呢?!

试着把正则表达式写得不要那么严格点,效率正常了。

 
##原来的正则表达式 ^2[0-9]{7}_(.*){1,}_USER_[0-9]{4}.(xls|xlsx)$ ##新的正则表达式 ^2[0-9]{7}_[\\w|-]{1,}_USER_[0-9]{4}.(xls|xlsx)$

通过比对,发现第二段匹配单号条件写为(.*),在文件名不匹配的时候,单号越长,匹配效率越差。

在明确写为[\\w|-]之后,只匹配字母/数字/减号,效率提高很多。

看来针对不匹配模式,如果字符串复杂度或者长度越长,表达式越模糊,执行效率越差。

转载地址:http://jolmd.baihongyu.com/

你可能感兴趣的文章
ES5.x 中long类型不支持time zone
查看>>
kudu之tablet设计原理
查看>>
kudu之CFile设计原理
查看>>
kudu之Compaction 设计原理
查看>>
ES2.x不支持 javascript问题的解决
查看>>
如何查看cdh使用组件的版本对应apache原生态版本
查看>>
kudu之维护操作
查看>>
kudu之一致性设计
查看>>
kudu之更改Raft配置的设计
查看>>
Kudu 1.8.0 编译安装配置(瘦身版)
查看>>
HBase - 数据写入流程解析
查看>>
HBase – 探索HFile索引机制
查看>>
HBase GC的前生今世 – 身世篇
查看>>
掌握 Ajax,第 8 部分: 在请求和响应中使用 XML
查看>>
掌握 Ajax,第 9 部分: 使用 Google Ajax Search API
查看>>
还在做外包的程序员们,快醒醒吧!
查看>>
安排,2020新kafka视频教程零基础到精通
查看>>
后端必备 Git 分支开发:规范指南
查看>>
28岁华为员工工资表曝光,牛逼的人注定会牛逼!
查看>>
工作后我变强了,暂时没秃...
查看>>