AI可以监控存储以检测多种工作负载的模式和性能。这里的工作负载是由各种输入/输出特征或应用任务生成的数据流。通过检测这些工作负载模式，AI可以帮助存储管理员洞悉哪些工作负载可能使他们面临最大化存储阵列的风险。此外，存储监视还可以帮助了解是否有任何额外的工作负载可以放入阵列中。而且，如果添加到阵列中，那么工作负载将造成多少中断。
例如，假设一家企业正在向流程中添加电子邮件服务器。在这种情况下，人工智能系统可以帮助预测存储阵列将能够满足该服务器的存储需求还是将其最大化。借助此类技术，存储管理员可以主动获取有关如何将不同的工作负载分配给不同的存储堆栈并最大程度地减少延迟的信息。因此，将AI集成到存储阵列，存储供应商和组织中可以优化存储堆栈。
开发期间修复并适配了一些lsif-java的问题，如位置范围信息错乱，召回多种遗漏的高亮词类型，适配非Maven仓库的索引构建。同时还修复了Spoon关于无法正确解析注释中的部分注解的问题，PR已被Spoon社区接受合并。
学习也不是说去瞎学，一定要有体系化的。首先跟你工作相关的，要体系化的去学习，从最下到最上体系化的去学习，学习完了以后你会有新的不一样的认识。把你的想法可以向你的团队说出来，向你的主管说出来。
学习也不是说去瞎学，一定要有体系化的。首先跟你工作相关的，要体系化的去学习，从最下到最上体系化的去学习，学习完了以后你会有新的不一样的认识。把你的想法可以向你的团队说出来，向你的主管说出来。
除了只读事务，这个优化的另一个场景是多分片读单分片写的事务，通过这个方案我们能将其优化为一阶段提交事务，在 TPCC 的测试结果上得到了 14% 的性能提升。
当前读事务优化
在上面的只读连接优化中，我们通过将仅使用快照读的连接摘出事务之外，来优化 COMMIT_TS 的获取。而如果是完全相反的情况 ——— 所有连接都是写操作或者带锁的当前读操作，那么我们完全不需要进行快照读。因此我们也做了这样一个优化：仅在第一次进行快照读时获取 SNAPSHOT_TS。
这个优化针对的是一些对 Serializable 有很强需求的场景：
BEGIN;
SELECT balance FROM accounts WHERE id = 0 FOR UPDATE; # 检查余额，需要加锁
UPDATE accounts SET balance = balance - 1 WHERE id = 0;
UPDATE accounts SET balance = balance + 1 WHERE id = 1;
COMMIT;
上面的 SQL 执行的是一个典型的转账场景，将 1 元从 id 为 0 的账户转到 id 为 1 的账户，在整个事务中都没有使用到快照读，因此针对这种场景我们会省略 SNAPSHOT_TS 的获取。
The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.
