|
锁定老帖子 主题：神奇的java正则表达式
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (6)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-01-07
搞了这么久，楼主怎么不把有问题的cookie贴上来啊？
不告诉我们症状，怎么帮你找出问题的根源？ |
| 返回顶楼 | |
|
发表时间：2011-01-07
最后修改：2011-01-07
引用 你会来解析一下这是为何，我说的性能，你提的是灵活性，有毛关系。
装*给雷劈就是你这种 引用 不是性能不行 是你不会用. (此处说的是性能问题.)
正则应该用在描述容易改变的规则. 比如文本的搜索条件,输入的校验等. 方便以后规则的更改.(此处说的是适用正则的场合) 我没说我会正则调优. 但是我知道用这么一大堆乱七八糟的正则,来解析一个格式几乎不变的字符串肯定是不恰当的. 正则实际上也是通过循环解析字符串来执行.过多子表达式嵌套造成过多的循环.循环期间对象内存和栈空间不能及时回收.所以才造成了异常. 如果让正则高手来做正则调优肯定会有很大的效率提高. 如果非要正则,我给你的建议,拆分成为多个短正则配合逻辑代码多次匹配. 正则是一个很好的工具. 用不好要怪自己.不要怪工具. 就好比用绷带当治疗 还嫌不给力 就说绷带垃圾? |
| 返回顶楼 | |
|
发表时间：2011-01-08
蓝皮鼠 写道 我的正则式不怎么强。但是见过也维护过超复杂的正则式，比如超过几十行的。
经验是正则式最好用于单行简单内容的匹配，如果内容太长的话很难保证有时会出错。 关于StackOverflow原来有次的出错原因是用正则式处理去空白，当空白行太多时正则式写的不好会错。 另外就是对于特殊字符，GBK中的日文等等，有时会导致解析一次几十分钟或者几个小时才能完成。细节原因也没有搞清楚，后来对于这部分自己写解析器搞定了。 最终建议：对于自己能控制的内容，用正则式问题不大。对于未知内容，用正则式有风险，而且比较大。 严重同意，我也一直有在用正则，正则在处理文本，如果源内容长度可控的情况下是没有问题的，如果你都不知道你要用来检索的内容有多大，不要使用正则，起码不要使用复杂的正则。 |
| 返回顶楼 | |
|
发表时间：2011-01-08
rochoc 写道 蓝皮鼠 写道 我的正则式不怎么强。但是见过也维护过超复杂的正则式，比如超过几十行的。
经验是正则式最好用于单行简单内容的匹配，如果内容太长的话很难保证有时会出错。 关于StackOverflow原来有次的出错原因是用正则式处理去空白，当空白行太多时正则式写的不好会错。 另外就是对于特殊字符，GBK中的日文等等，有时会导致解析一次几十分钟或者几个小时才能完成。细节原因也没有搞清楚，后来对于这部分自己写解析器搞定了。 最终建议：对于自己能控制的内容，用正则式问题不大。对于未知内容，用正则式有风险，而且比较大。 严重同意，我也一直有在用正则，正则在处理文本，如果源内容长度可控的情况下是没有问题的，如果你都不知道你要用来检索的内容有多大，不要使用正则，起码不要使用复杂的正则。 精通正则表达式上面 这点已经做了总结了 |
| 返回顶楼 | |
|
发表时间：2011-01-08
xingqiba 写道 对于正则表达式，请记住一句老话：“ 您有一个问题，用正则表达式解决。那您就有两个问题了。”
呵呵…… 正则匹配的确麻烦，但是它的效率真的不高吗？ |
| 返回顶楼 | |
|
发表时间：2011-01-09
最后修改：2011-01-09
afunti 写道 xingqiba 写道 对于正则表达式，请记住一句老话：“ 您有一个问题，用正则表达式解决。那您就有两个问题了。”
呵呵…… 正则匹配的确麻烦，但是它的效率真的不高吗？ 我对一般的复杂的表达式测试结果大约能到数十万到百万次每秒。 对于表达式的递归深度， 文本的长度都需要有清醒的认识。 但是， 总是觉得性能很高， 到处滥用， 就有问题了。 曾经REVIEW到过一次请求5000次正则的检查的代码。 无论性能多高， 不能滥用而已。 这玩意的特点就是： 要么一点事情都没有， 突然出现了， 就能打垮整个服务器的CPU. 在生产故障中， 我碰到不少因此正则不合理使用导致服务器压力特别大， 导致崩溃的事情。 |
| 返回顶楼 | |
|
发表时间：2011-01-09
蓝皮鼠 写道 我的正则式不怎么强。但是见过也维护过超复杂的正则式，比如超过几十行的。
经验是正则式最好用于单行简单内容的匹配，如果内容太长的话很难保证有时会出错。 关于StackOverflow原来有次的出错原因是用正则式处理去空白，当空白行太多时正则式写的不好会错。 另外就是对于特殊字符，GBK中的日文等等，有时会导致解析一次几十分钟或者几个小时才能完成。细节原因也没有搞清楚，后来对于这部分自己写解析器搞定了。 最终建议：对于自己能控制的内容，用正则式问题不大。对于未知内容，用正则式有风险，而且比较大。 比较同意你的说法。 我也遇见一些场景是： 1. 在以行处理的参数上， 单行文本太长， 导致性能问题 2. 表达式中包含了换行符， 导致性能问题 3. 大规模使用导致性能问题 4. 占溢出还是递归太多造造成的， 表达式太复杂，导致了深度递归。这个在JDK的表达式实现上比较容易出现， ORO的好象好很多。 |
| 返回顶楼 | |
|
发表时间：2011-01-10
看下http://blog.csdn.net/shixing_11/archive/2010/11/09/5997567.aspx;文章
这种正则非常容易形成死循环，这是JDK1.4以来遗留的一个BUG。到JDK1.6也未解决。以后用正则，一定要谨慎，对于大批量的数据校验最好避免正则，SUN对JDK这个BUG有专门说明，请看如下： http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5050507和 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6988218 |
| 返回顶楼 | |
|
发表时间：2011-01-10
hswx_11 写道 看下http://blog.csdn.net/shixing_11/archive/2010/11/09/5997567.aspx;文章
这种正则非常容易形成死循环，这是JDK1.4以来遗留的一个BUG。到JDK1.6也未解决。以后用正则，一定要谨慎，对于大批量的数据校验最好避免正则，SUN对JDK这个BUG有专门说明，请看如下： http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5050507和 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6988218 这个回复说到点子上了，如果真是因为某些bug引起死循环，那-Xss设置最大也没有用，最纳闷是，同样的要match的字符串输入并不能保证每次都会抛出StackOverflowError，而是偶尔才会出现，这样使得问题原因更难定位了。 |
| 返回顶楼 | |
|
发表时间：2011-02-15
最后修改：2011-02-15
sdh5724 写道 蓝皮鼠 写道 我的正则式不怎么强。但是见过也维护过超复杂的正则式，比如超过几十行的。
经验是正则式最好用于单行简单内容的匹配，如果内容太长的话很难保证有时会出错。 关于StackOverflow原来有次的出错原因是用正则式处理去空白，当空白行太多时正则式写的不好会错。 另外就是对于特殊字符，GBK中的日文等等，有时会导致解析一次几十分钟或者几个小时才能完成。细节原因也没有搞清楚，后来对于这部分自己写解析器搞定了。 最终建议：对于自己能控制的内容，用正则式问题不大。对于未知内容，用正则式有风险，而且比较大。 比较同意你的说法。 我也遇见一些场景是： 1. 在以行处理的参数上， 单行文本太长， 导致性能问题 2. 表达式中包含了换行符， 导致性能问题 3. 大规模使用导致性能问题 4. 占溢出还是递归太多造造成的， 表达式太复杂，导致了深度递归。这个在JDK的表达式实现上比较容易出现， ORO的好象好很多。 受教了。 正在做一个正则表达式，从网页html代码中提出table， 正则：<table(.|\\n|\\r)*?</table> 在js和一个桌面测试的正则工具下是正常的，但在java中当字符串长度超过826时就报栈溢出异常： Exception in thread "main" java.lang.StackOverflowError at java.util.regex.Pattern$CharProperty.match(Pattern.java:3343) at java.util.regex.Pattern$Branch.match(Pattern.java:4114) ...... 不知是我的正则有问题还是JDK的bug呢 |
| 返回顶楼 | |
