Thread creation in:

  • org.springframework.boot.devtools.filewatch.FileSystemWatcher#start
  • org.springframework.boot.devtools.livereload.LiveReloadServer.WorkerThreadFactory#newThread
  • org.springframework.boot.devtools.restart.Restarter.LeakSafeThreadFactory#newThread
  • ~org.springframework.boot.devtools.tunnel.client.HttpTunnelConnection.TunnelThreadFactory#newThread~
  • LeakSafeThread
  • RestartLauncher
  • ~org.springframework.boot.devtools.tunnel.client.TunnelClient.ServerThread~
  • ~org.springframework.boot.devtools.tunnel.server.HttpTunnelServer.ServerThread~
  • org.springframework.boot.devtools.remote.client.RemoteClientConfiguration.LiveReloadConfiguration uses an Executors.newSingleThreadExecutor().

Comment From: mhalbritter

The WorkerThreadFactory in the LiveReloadServer is used in a Executors.newCachedThreadPool and this executor is used every time there is a new connection to the LiveReloadServer. This could benefit from virtual threads, albeit it's not performance critical as we don't expect thousands of connections to it.

Comment From: mhalbritter

The LeakSafeThreadFactory is used by the LiveReloadServer to create the thread which calls accept on the socket and then dispatches to the executor described above. This could be a virtual thread, but as we only create one of it, i don't think it brings much benefit.

Comment From: mhalbritter

The TunnelThreadFactory is used by default in a Executors.newCachedThreadPool. This executor is used every time TunnelChannel.write is called. It looks like it could benefit from virtual threads.

Comment From: mhalbritter

The tunnel stuff is a leftover and going to be deleted, see #36808.

Comment From: mhalbritter

Until the platform threads in devtools prove to be a problem, we don't switch them to virtual threads.