内存键值缓存是否存储引用值？高频修改对象场景缓存适用咨询

问题1：大量对象频繁修改场景下使用内存键值缓存是否合理 #

完全合理，该选型非常贴合你的业务场景。

• 你当前做的是单Spigot进程内的本地缓存，本身就是为了降低高频读写对MySQL的压力，相比每次查询都走数据库，内存缓存的性能至少高2~3个数量级，完全能扛住城门血量、道具属性这类高频修改的需求。
• 唯一需要注意的是缓存和数据库的同步策略：对于这类频繁修改的非核心数据（比如城门血量），不需要每次修改都同步写库，用异步定时刷盘的方案就足够，比如每隔30s统一把所有修改过的缓存对象批量写入MySQL，既能保证性能，就算服务端异常崩溃，最多也只损失30s的战斗数据，完全符合MMO游戏的容忍度。
• 如果是玩家道具、城镇归属这类核心数据，可以在修改后立刻提交一个异步写库任务，不会阻塞主线程，也能保证数据可靠性。

问题2：缓存持有对象引用直接修改是否可行、性能是否高效 #

在你这个Spigot插件的单进程场景下，完全可行，而且是性能最高的方案。

• 你认知里的「修改后需要回写缓存」的规则，针对的是序列化存储的缓存（比如Redis、或者堆外内存缓存），这类缓存存的是对象的二进制序列化副本，你修改取出来的反序列化对象，不会影响缓存里存的内容，所以必须回写。但你用的是堆内内存缓存，存的就是对象的引用，你从缓存里拿到的对象和缓存持有的是同一个实例，修改之后缓存里的内容自然就更新了，完全不需要额外的回写操作。
• 这个方案的性能开销几乎可以忽略：你只需要在第一次加载Gate对象的时候读一次MySQL，之后所有的修改、读取操作都是纯内存的对象属性修改，连缓存的put操作都省了，你说的25次攻击场景，全程不会有任何数据库操作，也没有多余的缓存读写开销，完全符合Spigot服务端的性能要求。
• 唯一需要注意的并发问题：Spigot的事件处理默认是主线程单线程执行的，只要你所有的缓存对象修改都在主线程操作，不会有并发安全问题；如果你开了异步线程处理伤害计算，记得给对象的属性修改加锁，或者用AtomicInteger这类线程安全的类型存health属性，避免并发修改异常。

实用实现参考 #

你可以直接用Guava的LoadingCache实现你的缓存，开箱即用的加载、过期策略都有，不需要自己手写缓存逻辑：

// 示例：Gate对象的缓存定义
LoadingCache<Long, Gate> gateCache = CacheBuilder.newBuilder()
        .maximumSize(1000) // 最多缓存1000个城门对象，足够大多数服务器使用
        .expireAfterAccess(10, TimeUnit.MINUTES) // 10分钟没访问的城门自动卸载，节省内存
        .build(
                new CacheLoader<Long, Gate>() {
                    public Gate load(Long gateId) throws Exception {
                        // 这里写从MySQL读Gate对象的逻辑
                        return gateDao.getById(gateId);
                    }
                }
        );

使用的时候直接调用gateCache.get(gateId).setHealth(newHealth)即可，不需要任何额外的缓存写入操作。

内容的提问来源于stack exchange，提问作者Pandi