![](/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.