Double check virtual threads lock

[drojoy]

Hello, is it possible to avoid double check in scoped providers to implement manual locking, to achieve better performance in virtual threads and avoid pinning. Ex: @requestScope(doubleCheck=false)

[natros]

I think the Reusable scope uses the SingleCheck instead of DoubleCheck. No sure if it helps you.

[drojoy]

Well, Reusable is itself a scope, and the synchronized block issue is a major problem in custom short duration scopes, that's why I mentioned the Request scope, with virtual threads, we can avoid locking native threads using a reentrant lock, but not with a synchronized block.

If there is a way to implement manually the lock, we could use a reentrant lock.

[drojoy]

Or inherit the reusable scope in custom scopes.

[drojoy]

Olá Filipe vi que eras português 👍 não sei se percebeste o problema, mas com virtual threads um bloco synchronized bloqueia a thread nativa,  enquanto se for com um reentrant lock não bloqueia a thread, liberta a, num scope singletone isso não é um problema mas num scope de curta duração é, imagina que tens um custom scope dentro de um request a performance sofre, porque podes ter muitos locks físicos. Os custom scopes do dagger são muito práticos, mas têm o problema do double check em virtual threads.De: Filipe Sousa ***@***.***>Enviado: sábado, março 7, 2026 1:06:05 PMPara: google/dagger ***@***.***>Cc: drojoy ***@***.***>; Author ***@***.***>Assunto: Re: [google/dagger] Double check virtual threads lock (Issue #5138)natros left a comment (google/dagger#5138)I think the Reusable scope uses the SingleCheck instead of DoubleCheck. No sure if it helps you.—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.

[bcorso]

@drojoy just to make sure we're all on the same page, can you create a PR with the changes that you're suggesting.

[Chang-Eric]

It looks like this issue with virtual threads and synchronized was fixed in JDK 24 (https://openjdk.org/jeps/491).

From that link:

We previously recommended solving frequent and long-lived pinning problems by migrating code from using synchronized to using ReentrantLock. Once the synchronized keyword no longer pins virtual threads, such migration will no longer be necessary.

Since this was fixed and JDK 24 was released, and because changing to ReentrantLock will technically add another object allocation for every scoped provider which may cause issues for other users, we're leaning towards not making this change and just asking users who use virtual threads to update to JDK 24.

Please let us know if this doesn't work for you for some reason though, thanks!

[drojoy]

Ok,  cool I did know that. De: Eric Chang ***@***.***>Enviado: sexta-feira, março 13, 2026 6:56:30 PMPara: google/dagger ***@***.***>Cc: drojoy ***@***.***>; Mention ***@***.***>Assunto: Re: [google/dagger] Double check virtual threads lock (Issue #5138)Chang-Eric left a comment (google/dagger#5138)It looks like this issue with virtual threads and synchronized was fixed in JDK 24 (https://openjdk.org/jeps/491).From that link:We previously recommended solving frequent and long-lived pinning problems by migrating code from using synchronized to using ReentrantLock. Once the synchronized keyword no longer pins virtual threads, such migration will no longer be necessary.Since this was fixed and JDK 24 was released, and because changing to ReentrantLock will technically add another object allocation for every scoped provider which may cause issues for other users, we're leaning towards not making this change and just asking users who use virtual threads to update to JDK 24.Please let us know if this doesn't work for you for some reason though, thanks!—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.