Java缓存技术可分为远端缓存和本地缓存，远端缓存常用的方案有著名的redis和memcache，而本地缓存的代表技术主要有HashMap，Guava Cache，Caffeine和Encahche。远端缓存将在后面的博文中进行深入探讨，此处挖个坑，因此本篇博文仅覆盖了本地缓存，且突出探讨高性能的本地缓存。 本篇博文将首先介绍常见的本地缓存技术，对本地缓存有个大概的了解；其次介绍本地缓存中号称性能最好的Cache，可以探讨看看到底有多好？怎么做到这么好？最后通过几个实战样例，在日常工作中应用高性能的本地缓存。
2022年年初至今，团队持续在给业务应用做性能优化，主要目标是提高业务应用稳定性和降低业务应用的机器成本。到现在，代码层面的优化已经到了一定的瓶颈。所以就把优化的思路伸向了JVM的调优。有赞目前所有的Java应用采用的JDK版本是1.8.0_201，这个版本支持多个垃圾回收机制，比如CMS和G1等，而在有赞，除了个别应用有调整成G1垃圾收集机制的需求以外，其他所有应用都还采用着ParNew+CMS。有赞也将从G1身上挖掘出能够提供应用稳定性和降本的价值。
Spring Boot自2.0版本开始默认使用Lettuce作为Redis的客户端（注1）。Lettuce客户端基于Netty的NIO框架实现，对于大多数的Redis操作，只需要维持单一的连接即可高效支持业务端的并发请求 —— 这点与Jedis的连接池模式有很大不同。同时，Lettuce支持的特性更加全面，且其性能表现并不逊于，甚至优于Jedis。本文通过分析Lettuce的特性和内部实现（基于6.0版本），及其与Jedis的对照比较，对这两种客户端，以及Redis服务端进行深度探讨。
去年的Log4j-core的安全问题，再次把供应链安全推向了高潮。在供应链安全的场景，蚂蚁集团在静态代码扫描平台-STC和资产威胁透视平台-哈勃这2款产品在联合合作下，优势互补，很好的解决了直接依赖和间接依赖的场景。 但是由于STC是基于事前，受限于扫描效率存在遗漏的风险面，而哈勃又是基于事后，存在修复时间上的风险。基于此，笔者尝试寻找一种方式可以同时解决2款产品的短板。笔者尝试研究了一下Maven是如何处理一个项目中的直接依赖和间接依赖的，并且在遇到相同依赖时，Maven是如何进行抉择的，这里的如何抉择其实就是Maven的仲裁机制。带着这些问题，笔者尝试调研了Maven的源码和做了一些本地的测试实验。总结了这篇文章。
