2022-09-25

2022-09-25 杂谈

1 2	第一篇杂谈的前言：由于我整理不出来一个完整的思想体系（亦或没有这种必要），以后有什么想法我会先写下来发到博客上，作为参考和备份。

对“rust 是从语法上规避了 gc”的回复

rust 是从语法上规避了 gc

Rust 是在规避 GC，但其理由在于：如果我们能引入一种机制，使得我们能通过语法分析便可以回收堆上内存（如 String，Rust struct 等），那么就可以规避 GC。所以 Rust 引入了生命周期，所有权的概念。

要注意一点：生命周期，所有权等概念只在编译期有效。 当编译之后，在其生命周期的末尾会将其 drop 掉。

这有点像传统的栈上内存：先入后出。最先入栈的最后出栈，最先分配内存的最后 drop。

程序逻辑上并不会这么单线条，共享引用，循环引用等问题仍会发生。另一种常见的情况是你实在受不了一大堆生命周期标注，这时候就需要 reference-counter 来解决。

你有没有考虑过 reference-counter 就是一种 GC？

社区实现了另一种常见的 GC：Mark and sweep GC。在 Java 1.7 及之前使用的默认 GC 也是这个算法（CMS）。

所以 Rust 在语法上确实尽量规避 GC，但由于程序本身的特性（或考虑到各种抽象开至），GC 仍然存在。

首先，对于能通过 ID 对应的图片缓存才有意义，如果图片只有个 ETag 那缓存就是浏览器的工作，如果连 ETag 都没有那说明这个东西就不应该缓存。

需要缓存的图片可以分三类进行处理，我分别起了三个名字：

Hash 式：这类图片完全不会改动，并且已知固定链接，例如命运 2 的一个武器截图。这种情况下可以一次性缓存并用 ID 对应，不需要做其他处理。
API 式（Gravatar）式：这类图片有一个固定的链接，但图片可能会发生更新。我们通过向服务器发送带有 If-None-Match 或 If-Modified-Since 请求头的请求，判断返回码为 200（有变动）或 304 Not Modified 来更新并验证缓存。
Steam 社区式：例如 Steam 某游戏的商店页的第 x 张截图，这类图片有一个乱七八糟的 URL 不好找到对应关系，图片也有可能变动，我们先将这个图片的缓存返回给用户，同时后台创建一个背景任务比较并更新。这样可以得到最佳的用户体验，同时也能保证时效性。

同时图片的修改日期也应当缓存，可以删除 6 个月或 1 年以上未使用的图片来节省空间。

非 A，还是 A 的非？

我要保护环境，燃烧秸秆是污染环境，我为了不污染环境我就禁止燃烧秸秆

我要离开二中，二中搞了 xxx 规定，我只要跟 xxx 反其道而行之我就是离开二中

独裁就是自己拿意见，所以只要不是自己拿意见我就是民主

自责的要求，是在别人面前表现自责的态度，还是自己内心反省？

前者是一种表现，后者是一种自残。

当你在提到前者的时候，你把“我”作为了一个符号来批判，这个时候的“我”是之前的我。

后者则是批判“我”的整体集合。

LG 在这里觉得这两种符号上的区别（或分不清区别）是导致人们自我怀疑自我否定的罪魁祸首。