www.bilibili.com
获得徽章 9
- 用了一年多，终于在业余时间摸索出个人微调的三个 LLM 分别实现多模态识别视频课件，多模态添加字幕，还有英中单模态翻译，准确率已经有点高的可怕了，后续应该基本不需要我人工干预了，可以专心享受技术视频了。但是微调的成本确实也很高，我在大部分使用本地电脑（顶配 Mac M2）试错的情况下，尽量减少云微调的次数，还是花了 2w USD。最近在公司内部推广使用 AI 优化需求，也是必须用 RAG 压缩成本，否则太贵了。下一步优化就不从微调去做了，而是将识别的保存在向量数据库，并拉取各种 release note 辅助识别，优化新技术名词出现的识别，估计又得业余摸索几年。
一个识别的例子：
www.bilibili.com 展开
等人赞过
14 - Java 22 终于引入了关于 JVM Native Memory Tracking 的 JFR 事件，这样看统计还有趋势就更好看了，元空间，GC 占用内存（比如 CardTable），stringtable，internal 内存等等都更容易看出趋势了。但是通过 JNI 分配的内存（比如 Java DirectBuffer， MMAP Memory 等等）还是无法通过 JVM Native Memory Tracking 看到，估计等 Panama 一统堆外原生内存管理江湖之后，就能看到了。
关于 JVM Hotspot 内存哥块底层原理可以看这个系列：juejin.cn 展开
赞过 评论1 - 用了 IDEA 的 JFR 视图，它主要针对采集的 method sample profile 和 native method sample profile 做了火焰图，热点调用堆栈等等视图，并且和源码能对应上，源码处也有出现次数，很容易找到性能瓶颈或者性能热点去优化，比如笔者前一阵子发现的升级 Spring Boot 3.x 接入 Mcrometer 之后，尽量避免使用默认的 ObservationHandler 否则性能消耗太大，参考笔者提的 issue：github.com 展开赞过 23
- 试用Ottertune以及Akamas这两个AI自动数据库调优工具有感
OtterTune 和 Akamas 都是主要针对数据库的自动参数优化工具，它们使用人工智能和机器学习技术来分析数据库性能并自动调整配置以提高效率。这两个工具都旨在减少数据库管理员手动优化配置的负担，同时提升数据库的性能和资源利用率。
两者背后的模型都是基于组合模型，Ottertune 应该很大基于贝叶斯，Akamas 主要基于递归神经网络。
Ottertune 针对云数据库也有支持，比如笔者正在用的 AWS 的 Aurora。Akama 则是不仅针对数据库参数调优，也对于底层操作系统，虚拟机等等参数也有调优。这两个工具，经过笔者使用，感觉主要针对的是想自己搭建数据库的厂商。云数据库都在减少需要调参的参数，底层系统参数更是一般无法调整，还有目前大部分云数据库都在做存算分离，大大减少了水平扩容的难度以及成本，需要调优的其实更少了。但是，不想用云自己搭建数据库的厂商还是很多的，请个专业的 DBA，可能无法做到随着业务量改变针对当前业务量最优的参数，在这一点 AI 工具可以轻易做到。展开
评论点赞 - Project Leyden（保留 JIT 的同时增加启动速度，左图是 Spring Boot 3.0 的效果，加入了与本身的 AOT 的启动时间对比） 和 Project Valhalla 当前的进展（值对象效果，和原始类型一样栈上分配，右图）
等人赞过 评论7 - 统一回复 Java 21 虚拟线程问题：
1. ThreadLocal 继续用么？Java 开发组本来设计虚拟线程的时候，想去掉对于 ThreadLocal 的支持，但是由于使用的库太多，并且很多为了传参才用，并不是缓存，所以就保持了支持。像隐式传参的这种场景，继续用也没事儿，就是性能有所损耗。（不会影响 GC，生命周期随着虚拟线程终止，但是线程本地变量数量变多，哈希表变大，需要频繁清理）。千万别在虚拟线程的 ThreadLocal 放大对象。Java 开发组是想通过 ScopedLocal 替换掉 ThreadLocal（这个没有大哈希的问题），但是在 21 还是 preview。
2. 虚拟线程主要通过 Continuation 实现，虚拟线程栈会在切换的时候复制到 Continuation 中，切换回来的时候，复制回来，但是不是每次都全量复制。在切换回来的时候，线程栈帧懒复制，调用返回到哪个就复制回哪个，这对于像是 servlet 这种很多层调用的是很大的优化，因为栈深度可能有 上百层，但是实际业务只会用到头部几层，这样大大减少了切换的性能消耗。
3. 网络 io 方面，虚拟线程目前完全不会阻塞了。
4. 文件 io 方面，目前实现方式是遇到就增加一个平台线程来规避阻塞。这个会在 io_uring 引入到 JVM 支持后进行优化，到时候文件 io 也原生不会阻塞。
5. JFR，Thread Stack Dump，调试器， JVM TI 都可以兼容虚拟线程。但是要记住，调试虚拟线程可能也会让其他虚拟线程无法执行，因为载波线程是同一个
6. synchronized 以及涉及 ObjectMonitor 的还是会 pin 住载体平台线程，要在你的代码中避免使用。
7. 虚拟线程无法 getAllThreads()，这个方法返回的是所有平台线程
8. 所有 JMX 以及 java.lang.management 相关的都是处理平台线程，不支持 VirtualThread
9. 虚拟线程支持类似于 jstack 的 dump，但是命令有所不同，请通过 jcmd 获取。并且格式是 json，没有死锁信息（虚拟线程 dump 不会进入全局安全点STW所以无法获取一致性信息例如死锁等）展开等人赞过 评论4
![[呲牙]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_2.cd1e2bd.png)
个人成就