为什么使用最近最少使用的简单缓存机制？

Question

我使用JProfiler检查Java微服务，同时使用JMeter模拟并发用户。 使用JProfiler，我可以看到： 导航到方法find（），我意识到该方法有synchronized关键字

在我看来，这种方法导致线程被阻塞的问题。但为什么要使用它？我可以从微服务中禁用这个缓存机制吗？微服务是用Java编写的，它使用Spring，Spring Boot。

谢谢

我在Monitor History的相同JProfiler快照中添加了屏幕截图，以显示在ResolvedTypeCache类中花费的时间。有时候时间较少但有时却很大。

Answer 1

你的结论对我来说似乎是非常错误的，特别是当你暗示这是坏的或者有潜在的死锁时。

该类中有synchronized个方法的事实并不表示死锁。事实上，有多个线程在单个锁上等待 - 毕竟这是synchronized所做的事情。还要看那些时间，那些看起来像微秒，并且线程留在那里的最多是4000，大约是4ms - 不是那么多。

由于这是一个内部库，你可以做的很少，可能会建议他们实现一个ConcurrentHashMap来提高性能或者更好地自己制作一个补丁。

Answer 2

为什么使用LRU？大概是因为有值得缓存的东西。

为什么synchronized？因为此处用作缓存的LinkedHashMap不是线程安全的。它确实提供了idiomatic LRU mechanism。

可以用ConcurrentMap替换它以减轻同步，但是你会有一个不断增长的非LRU缓存，并且完全没有相同的东西。

现在你无能为力。最好的想法可能是与开发者联系，让他们知道这一点。总而言之，图书馆可能不适合您通过它的交通量，或者您可能正在模拟会出现病态行为的交通类型，或者您可能高估了这种情况的影响（不是冒犯，我＆＃39 ;我只是非常 Mulderesque 关于SO帖子，即＆＃34;信任no1＆＃34;）。

最后，无争议的同步很便宜，因此如果有可能将流量划分到缓存的多个实例，则可能以某种方式影响性能（不一定是正的）。我不知道图书馆的架构，所以可能完全不可能。