Optimize cache usage in DefaultConversionService and fix race condition

[PakhomovAlexander]

The usage of typeConverters and converterCache are optimized.

1. Redundant operations are removed, which boosts the performance (according to the ConversionServiceBenchmark) at ~ 2x.

2. The synchronized keyword is added to the critical methods that can be called from several threads. Now typeConverters and converterCache are consistent.

Here are the benchmark results that I've run on my Macbook 2,6 GHz 6-Core Intel Core i7, jdk-11.0.12.jdk:

Benchmark                                     Mode  Cnt         Score          Error  Units

Baseline:
ConversionServiceBenchmark.convertCacheHit   thrpt    5  27404123.384 ± 5692431.522  ops/s
ConversionServiceBenchmark.convertCacheMiss  thrpt    5   4923550.293 ±  461767.609  ops/s

Refactored (1):
ConversionServiceBenchmark.convertCacheHit   thrpt    5  48408342.853 ± 9369123.821  ops/s
ConversionServiceBenchmark.convertCacheMiss  thrpt    5   4842578.352 ±   34813.903  ops/s

Refactored + synchronized (1 + 2):
ConversionServiceBenchmark.convertCacheHit   thrpt    5  38918162.398 ± 10242478.879  ops/s
ConversionServiceBenchmark.convertCacheMiss  thrpt    5   4512350.735 ±   981537.261  ops/s

[CLAassistant]

All committers have signed the CLA.

[PakhomovAlexander]

Also, the original issue is not reproduced in this fix.

@wetted Do you think this fix is good enough?

[wetted]

@PakhomovAlexander thank you for the PR. I'm asking for reviews from those who know micronaut core better than I.

[sdelamo]

in which scenario did you get the race condition. In tests?

[PakhomovAlexander]

@sdelamo I've described the case with the race condition in this issue #10091

Here is the repo wich reproduces it https://github.com/wetted/core-10091-race-condition

TLDR; Yes, first I got the race condition on tests but then I managed to reproduce it in the main code. Basically, any application that starts context from different threads can face this issue.

[PakhomovAlexander]

Hi @sdelamo, could you please clarify the state of this PR? I wonder if the fix will appear in the upcoming 3.10.x release. Thanks!

[sdelamo]

@PakhomovAlexander it will be part of a 3.10.x release.