Request for Review : CR#6924259: Remove String.count/String.offset (original) (raw)
Krystal Mok rednaxelafx at gmail.com
Sat Apr 13 01:51:00 UTC 2013
- Previous message: Request for Review : CR#6924259: Remove String.count/String.offset
- Next message: hg: jdk8/tl/jdk: 8011172: JSR 310 DateTime API Updates II
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Nazario,
That's a typical substring leak case. Matcher.group(n) eventually calls String.substring() to return the result. Before removing the count and offset fields in String, that'll return a String sharing the value char array, which may cause memory leaks if you hold on to a small substring of a large string.
It's not your HashSet leaking memory, just the substring.
- Kris
On Fri, Apr 12, 2013 at 9:50 PM, wangsheng.0376 <wangsheng.0376 at 163.com>wrote:
hi, all,
I agree with you to remove offset, today when I run following code in jdk7(sorry I forget the detail version), my code is like this:
Pattern pattern = Pattern.compile(regex); Matcher matcher = pattern.match(content); while (matcher.find()) { String link = matcher.group(1); set.add(link);// set is a HashSet type } after I running for some time, I found that the 'set' object has memory leak, I found though 'link' is a part of 'content', but the value field in link variable is same as 'content' value field, difference is that the link offset field is not zero. So that mean the set(HashSet) is not store the 'link', it store the 'content' value field, it will cause the memory leak problem, So I am very happy to reomve the offset field. Best Regards =nazario.wang=
- Previous message: Request for Review : CR#6924259: Remove String.count/String.offset
- Next message: hg: jdk8/tl/jdk: 8011172: JSR 310 DateTime API Updates II
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]