k8s 之前学了尝试搭建自己的集群 (多台虚拟机), 结果无论如何都无法让所有 node 全部 Ready (装了 flannel 网络). 之后就放弃了.

短文小说: <长安的荔枝>

就打算买一个 Ace Pro 2 相机再加点套件. 记录下之后的自行车比赛和端午游玩.

可以戴耳塞. 耳塞很管用

合理, 主要有以下几点:

1. 一个功能一个分支：确保功能完整，便于问题回退，控制影响范围。合并到主线通过 MR ，git log 清晰记录提交范围。
2. 小提交原则：避免一次性提交完整功能。若功能开发中（已提交 5 次）遇 issue ，主线开发需选择回退（ revert ）或继续提交。前者需重新提交，后者可能因未完成功能导致主线无法运行。而一功能一分支、一 issue 一分支可快速切换修复 issue ，不受未完成功能影响。修复后，切回功能分支，rebase 解决冲突，继续开发。

假设你已经 commit (还未 push) 了 5 个 change, 功能还未开发完成. 这时突然出现一个 issue, 如果这个 feature 在主线而非分支. 那你是打算 revert 之前的提交, 还是直接修改继续提交 (6 个提交).
如果 revert, 那你得先 revert 之前的所有提交, 然后提交 issue, 之后还得重新 commit.
如果直接提交, 那你还未完成的 feature 也同步 push 到主线. 那很有可能会出现无法跑通的情况 (必尽你还未开发完成).

@recying5566 哈哈哈哈哈哈, 只要 6 万起, 能拉能运还便宜 [doge].

五菱宏光, 混动续航 1000KM +

https://www.bilibili.com/video/BV1SRo6Y2Eaf/

@heiya 首先大文件会占用过大的磁盘 IO, 如果云磁盘容量过低则 IOPS 也会很低.

在没有性能要求的情况下, 且数据库和 MINIO 不属于同台机器是可以使用 minio 的. 如果有性能要求, 那磁盘 IOPS 则会是瓶颈. 既然如此可以试试内网 OSS, 或者内网 S3. 内网的费用相对便宜实惠.


对于大文件是否需要 CDN 这个问题, 你得先明白 `CDN (Content Delivery Network)` 是什么. CDN 是一个内容分发网络, 将你提供的资源尽可能的靠近用户侧 (实际请求的用户, 例如 B 站的视频资源), 同时提供海量带宽.
如果你的文件不会频繁下载, 或者根本不会下载, 那 CDN 就不需要了. CDN 引入只会徒增成本 (资源成本 + 流量成本).

说实在的, 有 OSS 不用非得自己搭. 图啥啊?

自建存在以下问题:
- 安全措施 (即使 MINIO 有账户校验和链接校验, 但只要有漏洞数据就全丢了)
- 磁盘限制 (云厂商提供的硬盘是按照容量分配 IOPS 的, 你容量越小, IO 越小. 存个大文件直接把 IO 吃满了)
- 带宽限制 (你也说了带宽瓶颈了, 既然你是对外提供服务, 为什么不选择 CDN ?)
- 高可用 (自建没有现成的好)


PS: 如果只是出于学习的目的, 那尽管折腾.

@ebony0319 的确不错👍.

@ebony0319 是的, VT 是 JDK 的里程碑. 在 HTTP 侧的确能够显著的提升响应能力. 不过在日常业务开发中也能使用, 不过需要比原有的 Thread 有更多的规范. 滥用 VT 可能并不会提升性能, 还会降低性能 (上下文 Continuation).

在没有修复 synchronize 情况下, 只建议在最贴近 IO 部分使用, 尽可能减少组建中 synchronized 所带来的影响 (没修复, 也就是 JDK-21-LTS).

在目前的 JDK-24 (non lts) 中修复了 synchronize PINED Thread 的问题, 但类似本地方法调用还是会存在 PIN. 在日常开发是可以使用了, 不过还是需要注意 VT 数量. 平台线程的数量是和计算机硬件资源对等的, 而 VT 数量则是和 JVM 内存对等的. VT 数量越多, JVM 内存占用越高, 直到 VT 任务结束释放了 Continuation.

总结:
1. 在 JDK-21-LTS 不太推荐使用. 如果使用请尽可能贴近 IO 部分.
2. JDK-21-LTS 也能使用, 前提是了解 VT 内部机制 (上下文切换, Continuation, 锁机制, 本地方法站调用).
3. 如果在业务中, 我的建议是等下一个版本的 LTS 上线. 想上也可以, 建议增加 -Djdk.tracePinnedThreads=full, 在遇到 PINNING 时会打印堆栈.

@anyele 我知道

@ychost 我知道, 所以前面增加了 JDK-21-LTS 版本

就目前的 JDK-21-LTS 的虚拟线程还存在致命问题:

- 在使用 synchronized 场景下会将虚拟线程 PIN 到平台线程 (锁在了某一个线程上)
这是由于当前对 synchronized 的实现需要直到锁当前持有的线程对象. 而虚拟线程是上层包装出来的, 所以必须强绑到某一个平台线程 (Thread) 上才能实现. 如果在 IO 操作下会基本和平台线程无异.

- 在 Medium 中, Netflix 团队遇到使用虚拟线程死锁的情况.
这个问题和 synchronized 关联. 具体可以参考 [Medium Netflix Tech]( https://netflixtechblog.com/java-21-virtual-threads-dude-wheres-my-lock-3052540e231d)

虚拟线程不推荐使用.
1: 虚拟线程的出现是减少 IO 的产生, 如果是非 IO 操作使用虚拟线程只会增加应用负担.
2: 虚拟线程是通过用户态上进行上下文切换减少内核态切换. 虚拟线程使用 Continuation 实现的, 这个是个对象, 也就是会占用内存. 当你操作越多, 内存占用也会疯涨. 原有平台线程 (Thread) 则是由物理资源 (系统资源) 限制, 而虚拟线程则没有这层限制, 操作不好容易导致 OOM.

用 var 能够减少类型申明 (虽然可以通过 .val 快速申明), 但是会显示隐藏掉函数返回类型. 如果是一个新人进来看到一堆 var 关键字, 就得对每个方法进行 CTRL+Q 查阅方法返回数据类型, 或者进入方法内部查看, 相对不是十分便捷.

同样的, 由于 var 显示隐藏了对象的结构信息, 可以有效的把冗杂的类名或者泛型隐藏. 整体代码看起来会相对清爽 (但阅读同样存在障碍).

具体用还是不用, 一方面取决于团队内部, 还有一方面取决当前项目构型.
如果项目构型没有使用 var 关键字, 那尽可能不要使用, 会显著增加阅读代码的障碍 (虽然不是很大, 但有些人会觉得很头疼).
如果团队内部都支持, 建议在新项目内使用, 老项目则按部就班.

最好能在使用前与团队内部进行交流探讨, 让团队都了解这个特性, 并尝试了解他们所抵触的原因, 尝试对其进行化解才会更有效的推动新特性的使用.