Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8189598

ReentrantReadWriteLock might get GC'ed while lock is still held

    Details

    • Type: Bug
    • Status: Open
    • Priority: P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: core-libs
    • Labels:
      None

      Description

      Martin Grajcar reports on concurrency-interest:
      http://concurrency.markmail.org/thread/lfop7g7frfdse4xh

      """
      The parts of the ReentrantReadWriteLock holding no reference to it may lead to a situation where the ReentrantReadWriteLock gets GC'ed while its read and write locks are still in use. This is alright unless the ReentrantReadWriteLock is weakly cached as e.g., in Guava Striped, where it has lead to the bug https://github.com/google/guava/issues/2477.

      I'd suggest to add a reference to the enclosing class, e.g., by removing the static modifier. As all these objects are lightweight and not meant to have millions of instances, the cost is negligible. The advantage is decreased chance of buggy user code and avoiding lengthy workarounds like https://github.com/google/guava/commit/957c1a5455508120d224f6d0d8f3bf8afa3630f0.

      The cost benefit ratio seems to be good.
      """

        Activity

        There are no comments yet on this issue.

          People

          • Assignee:
            dl Doug Lea
            Reporter:
            martin Martin Buchholz
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: