Virtual threads and synchronized blocks don't play very well together, as they cause thread pinning. synchronized is fine when not doing any long-running operations, however.

We should examine our usage of synchronized and replace it with Lock when we guard long-running operations with them.

Comment From: dreis2211

Might be wise to investigate the same for ThreadLocal usages eventually. They don't play along nicely with Loom either. (Probably worth its own ticket, though)

Comment From: mhalbritter

Thanks @dreis2211. The ticket for that is #36681.

Comment From: mhalbritter

I've reverted that change. We need to examine where exactly we want to have virtual threads. And when we know that code can be run on virtual threads, we're going to refactor it to Lock IF there is blocking going on.

Comment From: mhalbritter

And we need to think about Checkstyle rules or something like this to not let synchronized in those cases creep in.

Comment From: mhalbritter

Should be a Lock

  • ConfigTreePropertySource uses a synchronized around IO operations. It's called from toString() and on getInputStream(). This could be a candidate for a Lock.
  • ApplicationTemp is public API and contains a synchronized around directory creation. This could be a Lock. Boot only uses this while bootstrapping Jetty.

Don't need refactoring

  • There are some synchronized in DeferredLog and DeferredLogs which do IO (calls to the logging system), but they are only called during startup on the main thread. No need to refactor this.
  • In the webserver support there are synchronized guarding the start / stop of the webservers. They are called on startup / shutdown from the main thread. No need to refactor this.