【问题标题】:Java tryLock release lock on multiple JVMJava tryLock 释放多个JVM上的锁
【发布时间】:2016-03-29 07:46:10
【问题描述】:

我在使用 Java 的 Linux 上遇到文件锁定问题 我在不同的主机(A 和 B)上有两个应用程序和用于文件锁定的共享文件夹。 在 A 中,我使用 channel.lock() 锁定。 然后我在 B 中调用channel.tryLock()。它抛出OverlappingFileLockException。没关系。 但后来我在 A 中调用channel.tryLock()(它抛出OverlappingFileLockException)。在此之后,在 B 中channel.tryLock() 返回有效锁,没有任何异常。

有人遇到过同样的问题吗?谢谢

【问题讨论】:

    标签: java nio filelock


    【解决方案1】:

    来自 Java Doc(方法 tryLock()

    如果由于持有重叠锁而未能获取锁 另一个程序然后它返回null。 如果获取锁失败 出于任何其他原因,将引发适当的异常。

    这意味着tryLock 方法将抛出一个OverlappingFileLockException,如果存在其他问题而不是其他具有锁的应用程序。

    如果你是多线程的,你应该知道这一点:

    代表整个 Java 虚拟机持有文件锁。 它们不适合控制同一虚拟机内的多个线程对文件的访问。

    如果您继续阅读该异常:

    OverlappingFileLockException - 如果锁与请求的重叠 此 Java 虚拟机已拥有该区域,或者如果另一个 线程已在此方法中被阻塞并试图锁定一个 同一文件的重叠区域

    所以我认为您的问题是您正试图从已经拥有锁的同一个应用程序中获取锁。你得帮我检查一下,但在这种情况下,它似乎不会返回null,而是抛出一个异常。

    另外:文档没有说明如果您尝试从同一应用程序锁定文件会发生什么。它总是说返回null,如果其他应用程序获得了锁:

    一个代表新获得的锁的锁对象,如果是 无法获取锁,因为另一个程序持有一个 重叠锁

    Link to JavaDoc

    【讨论】:

    • 我不知道这种行为方式的原因是什么,但是如果像我说的那样,那可能是有点设计缺陷。
    • 不是真的;文件锁是操作系统提供的一种相对底层的结构,用于促进跨进程同步,而不是进程内同步。
    • @TassosBassoukos 这很有道理,我不记得具体是怎么回事。感谢您的澄清。你能确认这是因为进程内同步吗?
    • 我认为你的回答是正确的;我只是想澄清为什么存在这种行为。至少在 Linux 中,出于性能原因,默认情况下所有线程共享相同的文件描述符表,因此另一个线程不是另一个程序...
    猜你喜欢
    • 2016-07-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-01-16
    • 2021-04-12
    • 2016-10-07
    • 1970-01-01
    相关资源
    最近更新 更多