使用 java.nio.file.Paths & jsfml loadFromFile 时出现死锁

Question

我一直在尝试调试使用 java.nio.file.Paths 导入从文件（.ttf 文件）加载字体时遇到的问题，结合使用 Paths.get()和 loadFromFile()，但似乎找不到解决方案。

问题代码如下：

import java.io.IOException;
import java.nio.file.Paths;

    public final Font FONT_UI_BAR = new Font();
    public final Font FONT_FREESANS = new Font();

    try {
                System.out.println("We get here, before loading");
                FONT_UI_BAR.loadFromFile(Paths.get("Game/resources/UI/Font.ttf"));
                System.out.println("I've loaded the first font");
                FONT_FREESANS.loadFromFile(Paths.get("Game/resources/fonts/freesans/freesans.ttf"));
            } catch (IOException e2) {
                System.out.println("[ERROR] Could not load font");
                e.printStackTrace();
            }

程序到达第一个打印语句但从未到达第二个。

我进行了线程转储，发现代码本身似乎存在死锁：

"main@1" prio=5 tid=0x1 nid=NA waiting
  java.lang.Thread.State: WAITING
      at jdk.internal.misc.Unsafe.park(Unsafe.java:-1)
      at java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
      at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:885)
      at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1039)
      at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1345)
      at java.util.concurrent.Semaphore.acquire(Semaphore.java:318)
      at org.jsfml.internal.SFMLErrorCapture.start(Unknown Source:-1)
      at org.jsfml.graphics.Font.loadFromFile(Unknown Source:-1)
      at assets.FontCatalogue.<init>(FontCatalogue.java:32)
      at assets.FontCatalogue.get(FontCatalogue.java:15)
      at screens.HomeScreen.<init>(HomeScreen.java:51)
      at controllers.Game.<init>(Game.java:74)
      at Main.main(Main.java:16)

我不确定如何从这里开始。如果不加载这些字体，我的程序将无法按我希望的方式运行。我试过加载其他字体，问题依旧。

奇怪的是以前加载其他文件都没有出现这个问题，比如这段代码：

TEMP_BG_01.loadFromFile(Paths.get("Game/resources/placeholder/full-moon_bg.png"));

它只是在我开始尝试加载这些字体后才开始。

理想情况下，我想找到一个仍然允许我使用这个包的解决方案，否则我有相当多的代码需要重写。不是最重要的，但建议仅使用另一个包应该是最后的选择。

任何想法表示赞赏。

编辑：有趣的是，这个问题不会发生在 Windows 机器上，只发生在我的 ubuntu-linux 机器上。 Windows 我团队的其他成员没有问题。显然，一种解决方案是改用 Windows，但谁愿意这样做呢：p

编辑 #2：事实证明，即使从 JSFML 中的纹理 class 加载，我现在也会收到此错误。我有一种感觉，当我最近更新我的 ubuntu 时我更新了我的 JVM，这突然引入了问题。我不能肯定地说，因为我不记得最近更新过，但似乎从 2021 年 2 月 21 日开始，使用 JSFML 从文件加载会导致死锁：/

Answer 1

如果您想继续使用 JSFML，您需要做的第一件事就是确定导致您处于死锁状态的初始故障。

SFMLErrorCapture class 中的代码不够健壮。如果 SFMLErrorCapture.start() 以任何方式失败，它将使信号量保持锁定状态。我怀疑这是破坏您的应用程序并使其陷入僵局的初始故障。

我建议将日志记录添加到 class，例如：

public static void start() {
    try {
        semaphore.acquire();
        capturing = true;

        nativeStart();
    } catch (InterruptedException ex) {
        ex.printStackTrace();
    } catch (Throwable t) {
        t.printStackTrace();

        // lots of other logging, probably to a file in /tmp

        // rethrow so original program flow isn't changed
        throw t;
    }
}

您可能还想添加更多日志记录以查看是否获得任何 InterruptedExceptions。这是信号量永远不会被释放的另一种方式，但我认为简单的升级不太可能触发这种行为变化。

而且，因为 finish() 也有可能以同样的方式失败（例如如果 nativeFinish() returns null，我认为这也是可能的故障模式...):

public static String finish() {
    try {
        final String str;
        if (capturing) {
            str = nativeFinish().trim();

            capturing = false;
            semaphore.release();
        } else {
            str = null;
        }

        return str;
    } catch (Throwable t) {
        t.printStackTrace();
        // lots of logging
        throw t;
    }
}

您可能需要将 throws Throwable 添加到这两种方法。

这也可能有帮助：

public static String finish() {
    try {
        final String str;
        if (capturing) {
            // chaining calls is BAD CODE!!!!
            // Say hello to NPE if you insist cramming
            // multiple calls in one line!!
            str = nativeFinish();
            if ( str != null ) {
                str = str.trim();
            }

            capturing = false;
            semaphore.release();
        } else {
            str = null;
        }

        return str;
    }
}

将这样的异步操作限制为一次一个从根本上被打破了。如果一次只能发生一个动作，那么为异步执行动作而增加的代码复杂性比浪费更糟糕，因为这样的复杂代码更容易出错，而当错误确实发生时，这种复杂性更可能导致不可恢复的故障。

如果您一次只能执行一个操作，只需使用一个 static synchronized 方法或在一个 static final 对象上的一个 synchronized 块中连续执行这些操作。

使用 java.nio.file.Paths & jsfml loadFromFile 时出现死锁

Deadlock occurring when using java.nio.file.Paths & jsfml loadFromFile

java

file

deadlock

java.nio.file

jsfml