You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Michael McCandless (Jira)" <ji...@apache.org> on 2022/04/22 15:36:00 UTC
[jira] [Commented] (LUCENE-1383) Work around ThreadLocal's "leak"
[ https://issues.apache.org/jira/browse/LUCENE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17526499#comment-17526499 ]
Michael McCandless commented on LUCENE-1383:
--------------------------------------------
> Even if the issue is closed, for those who want to know why ThreadLocal had to be fixed : [http://www.javaspecialists.eu/archive/Issue164.html]
Thanks [~adrian.tarau] – this was a very interesting read (even 12 years too late)!!! I wonder if modern JDKs have improved this situation?
> Work around ThreadLocal's "leak"
> --------------------------------
>
> Key: LUCENE-1383
> URL: https://issues.apache.org/jira/browse/LUCENE-1383
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/index
> Affects Versions: 1.9, 2.0.0, 2.1, 2.2, 2.3, 2.3.1, 2.3.2
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Priority: Major
> Fix For: 2.4
>
> Attachments: LUCENE-1383.patch, ScreenHunter_01 Sep. 13 08.40.jpg, ScreenHunter_02 Sep. 13 08.42.jpg, ScreenHunter_03 Sep. 13 08.43.jpg, ScreenHunter_07 Sep. 13 19.13.jpg
>
>
> Java's ThreadLocal is dangerous to use because it is able to take a
> surprisingly very long time to release references to the values you
> store in it. Even when a ThreadLocal instance itself is GC'd, hard
> references to the values you had stored in it are easily kept for
> quite some time later.
> While this is not technically a "memory leak", because eventually
> (when the underlying Map that stores the values cleans up its "stale"
> references) the hard reference will be cleared, and GC can proceed,
> its end behavior is not different from a memory leak in that under the
> right situation you can easily tie up far more memory than you'd
> expect, and then hit unexpected OOM error despite allocating an
> extremely large heap to your JVM.
> Lucene users have hit this many times. Here's the most recent thread:
> http://mail-archives.apache.org/mod_mbox/lucene-java-dev/200809.mbox/%3C6e3ae6310809091157j7a9fe46bxcc31f6e63305fcdc%40mail.gmail.com%3E
> And here's another:
> http://mail-archives.apache.org/mod_mbox/lucene-java-dev/200807.mbox/%3CF5FC94B2-E5C7-40C0-8B73-E12245B91CEE%40mikemccandless.com%3E
> And then there's LUCENE-436 and LUCENE-529 at least.
> A google search for "ThreadLocal leak" yields many compelling hits.
> Sun does this for performance reasons, but I think it's a terrible
> trap and we should work around it with Lucene.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org