ARTS 0815: 分隔链表、大删除是加活不是减负与协议栈如何一层层拆信封

每周完成一个 ARTS: 至少做一个 leetcode 的算法题、阅读并点评至少一篇英文技术文章、学习至少一个技术技巧、分享一篇有观点和思考的技术文章。(也就是 Algorithm、Review、Tips、Share 简称 ARTS)

Algorithm

中等难度,题目 https://leetcode.cn/problems/partition-list/description/?envType=study-plan-v2&envId=selected-coding-interview

image-20260816173848428

有几点需要注意:

1)双指针的 small、large因为会一直向后走,最后拼接答案的时候需要第一个节点

2)第一个节点就 0 所以需要第一个节点的后面一个,也就是 begin.next 和 later.next

3)Java 是引用传递,如果把 head 用 tmp 接收,之后 tmp.next = 0 页就让 head 的内容直接消失

4)因为 small 和 large 最后面会出现长度更长的情况,所以需要最终结束循环吧 next 都设置为 null

java
复制代码
class Solution { public ListNode partition(ListNode head, int x) { // 两个 piont 一个 res,最后 res 拼接两个 point ListNode small = new ListNode(); ListNode large = new ListNode(); ListNode begin = small; ListNode later = large; while (head != null) { if (x <= head.val) { large.next = head; large = large.next; } else if (x > head.val) { small.next = head; small = small.next; } head = head.next; } small.next = null; large.next = null; small.next = later.next; return begin.next; } }

Review

文章是这一篇:https://planetscale.com/blog/the-only-scalable-delete

原文讲 Postgres:大 DELETE 是加活不是减负。MySQL 结论一样,机制不同,InnoDB 的 DELETE 要注意这几件事:

删了不等于没了。InnoDB 只是打删除标记,旧版本在 undo 里,后台 purge 确认没有事务还要这个快照,才物理删行和二级索引。一次清几百万行会狂写 redo、undo、binlog,复制延迟容易飙升;长事务拖着旧 read view 时 purge 走不动,history list / undo 膨胀,别的一致性读还要顺着版本链回溯。删完页里的空洞只能给这张表后续插入用,.ibd 通常不缩小,想把磁盘还给操作系统得 OPTIMIZE TABLE 重建。

TRUNCATE (删除表的全部数据,但是表结构还在)是 DDL,隐式提交,事务里回滚不了,别先清空再插回。如果要删除的很多就通过建新表,而不是删除旧表的方式。要留的远多于要删的,就小批量 DELETE,让 purge 跟得上。日常过期数据按日期分区,到期 DROP PARTITION,别夜夜百万行 DELETE。外键 CASCADE 也可能把删一行变成一次巨型删除。

而且一般商业系统也不会删除用户的数据,普遍采取的做法是逻辑删除

Tips

1、搜索资料可以尝试使用 pi + pi-autoresearch

bash
复制代码
pi install npm:pi-autoresearch

2、cmd 脚本如果写中文的话,使用 GBK 编码(可以写一个 skill 专门用来写)

3、在 Vide Coding 的时候,如果有一些硬性条件比如:一个类不能超过 600 行、一个方法不能超过 40 行等,可以用 Hook 在编辑之后直接跑一个 bash 脚本,进行校验。这样虽然不会改变不合格的现实,但是会提醒 AI 你这里出问题了,记得修改!

4、agtens.md 最好做成「地图」而不是什么内容都写进去

5、为了方便 AI 读取代码,可以写一个 py 脚本,当作仓库的导览图,减少不必要的 tool call

6、如果有明确修改的类,直接 @xxx 不要再让 AI 浪费 token 使用工具去找相关的代码

Share

读《TCP/IP 详解》大概 5 页左右

一)

1、OSI 每一层数据叫 PDU (协议数据单元),当在网络层的 PDU 叫 IP 数据包

2、当第 N 层的 PDU 传输给 N - 1 层的时候,他会自动添加上标识信息,彼此之间不需要沟通。并且 N - 1 层承诺不查看 N 层的 PDU 信息。

image-20260816001925587

3、分层还有一个好处就是,不是所有的网络设备都需要实现完整的层,比如路由器、交换机、主机实现的层是不同的。理想情况下交换机只需要实现:数据链路层、物理层。

二)

1、下面演示了一台 Internet 主机分解 DPU 的大概流程:

image-20260816115902631

传入的以太网帧包含:48 位的目的地址(也叫 MAC 地址)和 16 位的以太网类型字段。这个 16 位以太网类型字段有三个:0x0800 表示 这个帧包含 IPv4 的数据报、0x0806 表示 ARP、0x68DD 表示 IPv6 的数据报。并且还会检测这个目的地址和接收到的地址是否匹配,这个帧被接收并且进行差错校验,以太网同类型字段用于处理他的网络层协议。

如果接受的帧包含 IP 数据报,以太网的头部和尾部的信息会被消除,并且将剩余的字节交给 IP 来处理,IP 会检测一些列字段如果发现目的 IP 地址和自己的 IP 地址匹配,并且数据报头部没有错误(不会检测有效荷载),那么就检测具体使用哪一个协议来解析,比如 1(ICMP)、2(IGMP)、4(IPv4)、6(IPv6)和 17(UDP) 等等。

0个评论
点击登录,快来和大家讨论吧~
表情
图片
暂无评论
leikooo
作者分享
DeepSeek Harness 缓存命中率太惊人了,有时候竟然能到 99%,看鱼皮哥的视频竟然还出现过 100% 😱 https://www.bilibili.com/video/BV1VkgK6NEZS
7
ARTS 0809: 反转链表、Shopify 如何用 MySQL 解决超卖与 AI 时代程序员的价值
5
译文:《SwiftUI 七年:平庸的故事》 SwiftUI 在 2019 年高调发布,本应成为苹果全平台成熟、可量产的 UI 未来。七年过去,到了 2026 年,它仍像一场永不结束的 beta:布局难预期、性能不稳、数据流混乱,还几乎没有可靠的向后兼容,开发者被迫写一堆 shim 和 workaround。 作者用苹果官方教程(甚至是有问题的)以及与 UIKit 的对比说明:SwiftUI 用“看起来方便”换掉了精确的工程控制。更深一层,他认为这反映了苹果从 Cocoa、Aqua、Auto Layout 那种不妥协的工艺,转向“够用就行”的企业文化。 SwiftUI 为何存在 苹果并非单纯想提供更好工具,而是不得不应对竞争:React、React Native、Flutter 让“一套代码多端跑”变得诱人;Mac 上原生应用又日渐被网页和 Electron 吃掉。SwiftUI 要同时拴住原生生态、并降低移植到 Mac 的成本。卖点是:响应式数据流、声明式布局、跨平台复用。 数据流 “单一数据源”听起来很美,实际却是 @State、@Binding、ObservedObject,再到 Observation / @Observable 的不断换代。你很难确定视图会更新几次、为何更新;它该忽略的变化会反应,该关心的变化又可能忽略 - - 像个黑盒。 布局系统 基于尺寸协商的布局在 Keynote 里很合理,做浮动视图、自定义侧边栏时却极度不稳定。官方教程里一个很普通的侧边栏,多年仍有问题。布局脆弱到最后往往只能上 GeometryReader - - 一旦用了,声明式优势就没了,还要手算坐标,而且下一版布局规则一变,数学还得重写。 API 稳定与功能对等 代码里满是 if #available。滚动收起键盘要到 iOS 16;工具栏定制很晚才来;网络图片 AsyncImage 要到 iOS 15,缓存相关 API 到 2026 年 7 月仍在 beta。旧 API 常被换掉(如 NavigationView → NavigationStack),开发者要维护多套实现,等于替苹果做 QA。对比 Android 的 Jetpack Compose 可作为依赖打包回退到旧设备,SwiftUI 做不到“写最新 API、稳定回退”。 性能 在真实对比里,即便做了后台解码等优化,SwiftUI 图片网格滚动仍明显不如 UIKit。若展示一堆 JPEG 都得靠顶级芯片撑,架构本身就有问题。 跨平台神话 苹果说的是“学一次、到处用”,不是“写一次、到处跑”。iOS 上学到的布局很少直接适用 Mac;同一套 view 跨平台实现也不一致。结果常变成:学一次、再学一次、某处能用、处处要调。 哲学转向 最大的问题是“够用就行”:覆盖 90% 用例就算成功,用 velocity 掩盖质量下降。作者列举系统与一线应用中的各种瑕疵,认为这不是偶然,而是苹果主动降低质量门槛 - - 所以即使过了七年,他仍不信任 SwiftUI。 结论 对构建稳定、高性能、可维护系统真正重要的部分,SwiftUI 几乎都有问题。它不是“极差”,而是平庸 - - 用假便利换真精度,要么你花时间给框架打补丁,要么把半成品发出去。作者更宁愿继续用“遗留”的 UIKit / AppKit。 最后小总结: 最让人不能接受的不是“SwiftUI 还有 bug”,而是它把“看起来很快”当成了工程上的完成态。声明式、预览、跨平台,每一项都在秀高级感,可真正写进业务后,你面对的是难预测的重绘、脆弱的布局、层层 #available,以及把兼容和排错外包给业务方的现实。七年够长了,若还靠“框架还年轻”解释,那更像是对标准的侮辱。技术选型从来不只是语法偏好,而是你选的是可预期性、可维护成本,以及对用户体验的态度。平庸的“成功”往往比明显失败更危险 ,你说它能上线、能 demo、能交差,但是却在细节里一点点磨损信任。工具可以换代,但对质量的要求不该跟着一起降级。
4
ARTS 0802: 合并有序链表、AI 时代的技术断层与 TCP 200ms 延迟之谜
5
Spring 团队开发者布道师 Josh Long,从 2011 年起每周二坚持写 This Week in Spring https://spring.io/authors/joshlong,大概 15 年半从未间断,到现在大概写了 800 期以上😱 大佬在采访里他说,写博客不是额外负担,而是逼自己整理每周所学的「强制机制」——反正本来就会刷社区动态,写出来既方便自己,也帮到别人。更重要的是 Spring 一直在变:微服务、AI……永远有新东西可聊,停一周就容易掉队。一旦养成习惯,坚持往往比重新开始更容易。 这种级别的大佬都还在用周更逼自己不掉队,我更没理由再拖了。还有之前左耳朵耗子大佬说的 ARTS 打卡,我老实说只撑了两周,真的需要捡起来了,加油✊
10
下载 APP