使用 java.nio.file.Paths & jsfml loadFromFile 时出现死锁
Deadlock occurring when using java.nio.file.Paths & jsfml loadFromFile
我一直在尝试调试使用 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 从文件加载会导致死锁:/
如果您想继续使用 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;
}
}
您可能还想添加更多日志记录以查看是否获得任何 InterruptedException
s。这是信号量永远不会被释放的另一种方式,但我认为简单的升级不太可能触发这种行为变化。
而且,因为 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 导入从文件(.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 从文件加载会导致死锁:/
如果您想继续使用 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;
}
}
您可能还想添加更多日志记录以查看是否获得任何 InterruptedException
s。这是信号量永远不会被释放的另一种方式,但我认为简单的升级不太可能触发这种行为变化。
而且,因为 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
块中连续执行这些操作。