linghengqian
commented
1 month ago - Please note that Loom will eventually address pinning of
synchronized– see this Java 23 EA announcement https://inside.java/2024/06/22/quality-heads-up/ . I kind of doubt that this would be a waste of time. - Downstream developers are free to use
SDKMAN!to switch to OpenJDK 23 EA and OpenJDK 24 EA for testing. The loom variant is located on the Project Loom Early-Access Builds page at https://jdk.java.net/loom/ .sdk install java 23.ea.29-open sdk use java 23.ea.29-open
sdk install java 24.ea.8-open sdk use java 24.ea.8-open
funky-eyes
lightClouds917
Why you need it?
适配jdk19开始的虚拟线程特性,防止synchronized导致虚拟线程pinned后线程阻塞 你可以在jdk19及以上版本增加 -Djdk.tracePinnedThreads=full 参数,使用seata-samples和seata-server.将其使用的线程池改为虚拟线程池进行测试,并且找出所有会将虚拟线程pinned的代码进行修正.当然你也可以直接阅读代码进行判断该问题是否存在,这个任务应该将server和client侧一并进行修正 注: 理论上所有单例模式,双检锁等行为存在的synchronized 对虚拟线程不会有严重影响,因为在其完成首次调用后,不会再进入synchronized所在的代码块 Adapt to the virtual thread feature introduced in JDK 19, preventing thread blocking caused by synchronized leading to virtual thread pinning You can add the -Djdk.tracePinnedThreads=full parameter in JDK 19 and above versions. Use seata-samples and seata-server to switch their thread pools to virtual thread pools for testing purposes, and identify and correct all code segments that may cause virtual thread pinning. You may also directly review the code to assess whether this issue exists. This task should include corrections on both the server and client sides.
Note: In theory, behaviors like singleton patterns and double-checked locking involving synchronized do not significantly impact virtual threads because once their initial invocation completes, they do not re-enter the synchronized code block.
How it could be?
A clear and concise description of what you want to happen. You can explain more about input of the feature, and output of it.
Other related information
Add any other context or screenshots about the feature request here.