![](/img/trans.png)
[英]How to use Paths(java.nio.file.Paths) in nashorn javascript
[英]Deadlock occurring when using java.nio.file.Paths & jsfml loadFromFile
我一直在尝试使用 Paths.get() 和 loadFromFile() 的组合使用 java.nio.file.Paths 导入来调试从文件(at.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)
我不确定如何从这里开始。 如果不加载这些 fonts,我的程序不会像我想要的那样 function。 我已经尝试加载其他类型的 fonts 并且问题仍然存在。
奇怪的是,过去加载其他文件时并没有出现问题,例如以下代码:
TEMP_BG_01.loadFromFile(Paths.get("Game/resources/placeholder/full-moon_bg.png"));
它只有在我开始尝试加载这些 fonts 时才开始。
理想情况下,我想找到一个仍然允许我使用这个 package 的解决方案,因为否则我有相当多的代码要重写。 不是最大的交易,但建议仅使用另一个 package 应该是最后的手段。
任何想法表示赞赏。
编辑:有趣的是注意到这个问题不会发生在 Windows 机器上,只有我的 ubuntu-linux 一个。 我的团队在 Windows 上的 rest 没有问题。 显然,一种解决方案是 go 并使用 Windows 代替,但谁愿意这样做:p
编辑#2:事实证明,即使从 JSFML 中的纹理 class 加载,我现在也会收到此错误。 我有一种感觉,当我最近更新我的 ubuntu 时,我更新了我的 JVM,这突然引入了问题。 我不能肯定地说,因为我不记得最近更新过,但似乎截至 2021 年 2 月 21 日,使用 JSFML 从文件加载会导致死锁:/
如果您想继续使用 JSFML,您需要做的第一件事是确定导致您陷入死锁 state 的初始故障。
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
。 这是信号量永远不会被释放的另一种方式,但我认为简单的升级不会触发这种行为改变。
而且,由于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
方法或在static final
object 上的一个synchronized
块中连续执行操作。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.