Describe the bug
It is possible to encounter an unexpected crash due to using the same hashmap (variable name is repository, in WeakHashMapCacheStorage), from different methods. Of these methods, one method puts the value in that repository hashmap, and another method is getting the value for a key. One more method named as clear() is also modifying the hashmap and making it empty. However, there is no synchronization between these three methods. As a result, anytime due to the existence of multiple threads, the program may crash.
Expected behavior
No cash is expected
Additional context
When I investigated the WeakHashMapCacheStorage class, I found that the repository is a shared variable that is used at Line 37, Line 43 and Line 47. Here, unexpected crash or inconsistency may occur if multiple threads interleave.
Environment(please complete the following information):
I ran the test on an Ubuntu 20.04 LTS machine using OpenJDK 1.8.0_312.
Describe the bug
It is possible to encounter an unexpected crash due to using the same hashmap (variable name is repository, in WeakHashMapCacheStorage), from different methods. Of these methods, one method puts the value in that repository hashmap, and another method is getting the value for a key. One more method named as clear() is also modifying the hashmap and making it empty. However, there is no synchronization between these three methods. As a result, anytime due to the existence of multiple threads, the program may crash.
Expected behavior
No cash is expected
Additional context
When I investigated the WeakHashMapCacheStorage class, I found that the repository is a shared variable that is used at Line 37, Line 43 and Line 47. Here, unexpected crash or inconsistency may occur if multiple threads interleave.
Environment(please complete the following information):
I ran the test on an Ubuntu 20.04 LTS machine using OpenJDK 1.8.0_312.