應該這個推文來的1

透過在library外包java.util.concurrent的方式避開synchronized還真不錯

我在公司看到有同事下單成功，所以現在是....賣光缺貨中的樣子 日本雅虎商店是10/31補貨哈

想買來試試看...不然為了滑鼠好麻煩

好像是說會因為利用到第二個表的method所以也會利用 ForkJoinPool.ManagedBocker

找到一個 wiki1 ，不知道哪邊有更新的

這內容也太長...看得好累XD

得增加機器數量了（！？

每次想想系統這樣也能跑，這行業也是很厲害XD

想說看到先貼過來一下

--
寫backend來看，大概在意效能跟好不好寫，現在Loom正式還沒出來，看看之後的效能比較吧。另外像裡面提到的Structured concurrency，通常意識到的機會也不多，很多時候後端應該都是一個request一個coroutine吧？我自己想要同時取多個東西的狀況或是在啟動(launch)新的coroutine的情況不太多。所以雖然有更自然的Structured concurrency語法，但用的機會不多的話，好處就比較少？ JEP 437: Structured Concurrency (Second Incubator)1 但Java 這 API 看起來也好麻煩，得自己 join 之類的。

另外影片內好像沒提到loom在除錯時看stacktrace應該會比較方便，這個感覺就差很多啊。

有人有用起來比較過嗎？因為公司不能用所以都還沒認真用過，只能在 opensource project試試看了

終於build index時有些功能還能用，不然之前連想稍微看一下code都得等他跑才能find by class之類

瞬間20，然後令人期待的loom在21可能會進去wow

不是不能理解，但通常沒看到說thread-safe可以共用的都不太敢這樣嘗試 XD

然後看到裡面 comment 的 FileChannel Closes When Interrupted1 竟然有 setUninterruptible2 ，但這種實作就忽略吧

阿對，我搞錯了0rz 不知道哪邊來的印象有東西用Rust實作

已經一陣子不少middleware都是把原本Java版本用C類/Rust實作後標榜相容，ScyllaDB，redpanda都常在我timeline看到

都要重寫，何不開始用Rust XD

最近跟同事也聊過日本的資遣，日本跟台灣好像差不多，都是對資遣理由比較嚴格，不然就是公司跟員工自己橋好

我自己是一直在用 1password，平常也沒確認所有細節，看來該好好在看一下各家給的資訊了。

另外剛好看到這篇 Not in a million years: It can take far less to crack a LastPass password1

Java 17 baseline，該升級了～

so sad...QQ

雖然不知道多少比例是工程師，這陣子這麼多公司裁員，轉職市場暫時會競爭激烈吧

影片1

記得 java.util.concurrent 下應該BlockingQueue類的也有，所以應該會蠻方便的

Moving Java Forward with Java 191 看了一下，雖然沒有詳細的資訊但真是期待不然寫非同步後的維護跟code review都好耗精神