问题描述
我一直在尝试使用 Paths.get() 和 loadFromFile 的组合来调试使用 java.nio.file.Paths 导入从文件(.ttf 文件)加载字体时遇到的问题(),但似乎无法找到解决方案。
问题代码如下:
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 中的 Texture 类加载时也会收到此错误。我有一种感觉,我最近更新了 ubuntu 时更新了 JVM,但突然出现了问题。我不能肯定,因为我不记得最近更新过,但似乎从 2021 年 2 月 21 日开始使用 JSFML 从文件加载导致死锁:/
解决方法
如果您想继续使用 JSFML,您需要做的第一件事是确定使您处于死锁状态的初始失败。
SFMLErrorCapture
类中的代码并不健壮。如果 SFMLErrorCapture.start()
以任何方式失败,它将保持信号量锁定。我怀疑这是破坏您的应用程序并使其陷入僵局的初始失败。
我建议在类中添加日志记录,例如:
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
。这是信号量永远不会被释放的另一种方式,但我认为简单的升级不太可能触发这种行为改变。
而且,由于 finish()
也有可能以相同的方式失败(例如,如果 nativeFinish()
返回 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
方法或在 synchronized
对象上的一个 static final
块中连续执行操作。