这些可见性的问题，实际上属于 Instruction Set Architecture (ISA)，不属于编程语言。
每个 CPU 指令集都定义了自己的 CPU 上哪些内存操作在什么情况下可见，都不一样的，这是问题非常复杂。

一个高级程序设计语言，像 C 这种的，当然不需要程序员去处理不同 CPU 的不同行为，不然它就不叫 高级 语言了。
对这些内存操作的行为，高级语言必须有统一的定义，让这个语言写的程序在不同 ISA 上能得到相同的结果。这个定义叫做 memory model ，比如
https://en.cppreference.com/w/c/language/memory_model
https://en.wikipedia.org/wiki/Java_memory_model
https://go.dev/ref/mem

存在 cache 的情况确实会有不可见的问题（考虑一下 CPU 上没有 cache ，所有 core 直接写到主内存上的情况）。但你看 Go memory model 里面根本没出现过 cache 这个词。
就是说 Go 的这套定义里面，就没有 cache 这个东西。Go 的定义里面，程序的行为就像没有 cache 一样（因为他的文档里就没写 cache 的事），所以只要一个 write 发生在 read 之前，且这个 write 之后 read 之前没有发生其它的 write ，这个 write 就被这个 read 可见。
所以这个文档全在讨论顺序的问题。

楼主发的代码显然有明确的执行顺序，这个顺序显然满足上面的要求，所以内存操作是可见的。


顺便一说，程序员不需要知道 ISA 上的这些定义，这本来就是个高端问题。但是 x86 上的内存操作的行为特别简单，所以总有人写代码的时候依赖于这些 x86 的行为，实际上写的代码都是 undefined behavior ，还觉得自己特别厉害，写文章讲解什么内存可见性的问题，估计楼主是这种东西的受害者。

@Rehtt
@stinkytofu
在这件事情上，一个弹窗应该把其它所有东西都挡住。
比如 Windows 上请求管理员权限的弹窗，甚至会把所有东西（包括不重叠的东西）都置灰。这个网页上有很多例子。
https://learn.microsoft.com/en-us/windows/security/application-security/application-control/user-account-control/how-it-works

或者退一步，弹窗是一个整体，那个下划线和下划线对应的文字是另一个整体。这两个整体的东西不应该交错，要么 A 在上面，要么 B 在上面。A 的大部分都在 B 的下面，有一小部分在 B 的上面，这不是正常行为。

或者再退一步，现在要把 B 放在 A 上面但是需要开一个天窗，我认可有这样的需求。但我不认可有人需要开天窗显示出来一条下划线，而且我不认可“开天窗”是一个常见且普通的需求。

所以，一条下划线被显示在一个弹窗的上面，是一个 bug 。
我觉得这个点本来就很清楚，我真不懂为什么需要这样长篇地解释一件非常浅显的事情。

从 GitHub 的 issue 来看，属于很明显的 bug
问题很简单，其实就一句话

弹窗没把该挡住的东西挡住


讨论 z-index 就变成 xy 问题了，需求是该挡的东西都要挡住，z-index 是 y 问题

不同的人对待软件的态度不一样，比如有人说
> 明明可以传入 zindex 解决的问题

问题在于，有的人会以更认真的态度对待工程问题。
苹果之前的键盘会坏，当然可以说 “找售后换一台就能解决”，不过我们还是希望键盘本来就不坏。
某某车的发动机烧机油，也可以说 “机油不够了补上就能解决”，那有的车企还是会让发动机本来就不烧机油。

这个项目的人明显没打算修，指着糊弄过去就完事了，确实说了一大堆看起来友善专业的话，但实际上放着一个明显的 bug 却没有要修的意思。也算不上大厂风范吧，很多人就是没那么认真而已。
这就是常规情况，不值得这样，我都直接走人的。

@forgottenPerson
@iOCZ

学好数学需要的能力和写代码需要的能力不一样。能学好数学的人不一定能写好代码，反过来也一样

学数学需要的能力大约是做算法题的能力，有人能做从没做过的算法题，这种人通常能轻松学好数学。
做算法题需要 凭空 想出来一个解法，这个解法不能或者很难从题目中 推理 得到。

但是实际写代码需要 推理能力，实际问题的实现方式都可以从需求推理得到。
工作中经常花费大量时间在解决 bug 上，大多数情况下，解决 bug 需要的就是在一个很长的逻辑链条上做推理，这种推理对大多数人来说非常困难，但也有人做起来很容易。所以经常会出现一个 bug 有人花了一周没解决，换另一个人来半天就搞定了。
Advent of Code 的题目也是这一类的，所以有的题目别人用时一二十分钟，自己来写可能要写一整天。

总之这是两种很不一样的能力，所以经常有某著名软件工程师面试算法题没过这种事情。

@wniming
16 个寄存器需要 4 位来编码，31 个需要 5 位，这个应该是最主要的原因。
比如 inc eax 只需要 1 个 byte （ 8 位）来编码。如果寄存器需要 5 位，就不太可能放在 1 byte 里面。（ ARM 好像也没有 inc 这个指令）
所谓 CISC ，是指在一条指令里面可以同时访问内存和做运算。比如 add eax, (ecx)，是 eax += *ecx ，这条指令在 x86 上面只占 2 bytes
在 RISC 上面需要先 load edx, (ecx)，再做加法 add eax, edx ，RISC 上面这两条指令很可能都要 4 bytes ，一共 8 bytes 。而且 load ecx 需要多用一个寄存器 edx 来保存结果。也就是 RISC 需要更多的寄存器来做到的 CISC 一样的事情。
指令短是 CISC 的一个重要设计目标，到 RISC 的年代不在乎这个事了，所以有这个差别。

CPU 实际有多少个寄存器和指令上定义的寄存器数量无关，CPU 有一部分专门来处理这个事情
https://en.wikipedia.org/wiki/Register_renaming

加密短的数据不可能耗时达到毫秒级
openssl speed -evp aes-128-gcm -bytes 16
在我的机器上只需要 16ns ，这个测试的结果显然没有包含访问主内存的时间（已经在一级缓存上）

自创的加密算法安全不安全？这个问题有标准答案，不安全
在某个项目上是不是适用？ 1 楼也已经答了，对没有价值的数据适用
有多大可能被破解？这个得给钱，不然不可能有高手帮你评估破解难度

@yzbythesea

我本来也想说这部分代码 "pretty much directly copied over from Intel's own implementation"
但是查了一下 commit 的作者
https://github.com/openjdk/jdk/commit/a4e9168bab1c2872ce2dbc7971a45c259270271f
https://github.com/vamsi-parasa

他的 GitHub 上写着 Intel ，那我只能认为这个事情是 Intel 干的了。
不过 openjdk 这种大项目理应自己认真测过再合并，结果没有。

这里有另外一个原因
比如
create table test(x int unique, y int unique, z int);
insert into test select 1, 1, 1;
insert into test select 2, 2, 2;
insert into test select 3, 3, 3;

然后执行 upsert ，insert into test select 1, 2, 3 on conflict do nothing;
这样当然没问题

如果要 returning 冲突的结果，insert into test select 1, 2, 3 on conflict do nothing returning *;
你希望它返回这个结果么？通常不期望这个结果，在 unique 的东西上只返回一行比较符合直觉。另外要返回这个结果的话，数据库需要把所有的 unique constraint 都扫一遍。
x | y | z
---+---+---
1 | 1 | 1
2 | 2 | 2
(2 rows)

如果要 update ，insert into test select 1, 2 on conflict do update set z = 0;（当然这一句执行不了，do update 需要有一个指定的 unique constraint ，叫 conflict_target ）
你希望它把表修改成这样么？同上，通常也不期望这个结果。
x | y | z
---+---+---
1 | 1 | 0
2 | 2 | 0
3 | 3 | 3
(3 rows)

这个功能的设计应该是说在 do update 的时候只修改一行，所以必须指定 conflict_target
要写成 insert into test select 1, 2, 0 on conflict (x) do update set z = 0;
表被修改成
x | y | z
---+---+---
2 | 2 | 2
3 | 3 | 3
1 | 1 | 0
(3 rows)

当然楼主写的 SQL 里面有指定 conflict_target ，但有没有 conflict_target 的结果需要做成一致的，所以只有现在这样应该是唯一的合理结果。

https://en.m.wikipedia.org/wiki/Timestamp

timestamp 指的是邮戳上那种日期时间。

邮戳上当然不写时区，SQL 标准里面的 timestamp 类型也不带时区。如果你永远在一个不带夏令时的时区里面，就可以用这个类型。但数据库不知道这个时间是哪个时区的，你可以写在代码里面或者在系统上设置。单看这个时间戳本身，实际上不知道它具体是什么时间。

如果给上面说的这种戳加上时区，比如
2024-05-06 19:20:21 +10
那么这个戳就是一个具体确定的时间，这个类型在 postgres 里面叫 timestamp with time zone
postgres 只关心它具体是什么时间，你输入进去的时区不重要，也没有存。
这个类型实际上就是 unix time ，并且在输入输出的时候帮你转换字符串。

还有个 time with time zone 类型，文档里说了这个类型根本没用，也是 SQL 标准里面的。

@nevadax

有的公司完全不支持远程，有的公司全员远程，也有的公司一半远程

如果你觉得远程是好事，和不支持远程的公司相比，你应该更喜欢一半远程的公司才对，当然全员远程的更好。
如果要喷，也是到不支持远程的公司发的帖子下面去喷，“你们这什么垃圾公司居然不支持远程”。

支持远程的公司本来就是少数，能支持一半已经很好了
请不要走这种极端路线，一说远程工作就要全员无条件远程工作，一说开放就是在药和疫苗都没有的情况下全体无条件开放

那位大佬可以帮你看，直接找他就好了，不用来发帖子

左脚刹车是高端技术，会的人不多，只要不是手动挡都可以左脚刹车，和特斯拉没关系，特斯拉也没有更适合左脚刹车。

看到很多人在争单踏板模式好不好用，说一个没人提到的点。

汽车匀速过弯是最安全的，这样车可以获得最大的向心力。所以在弯里保持匀速就可以获得最大的弯道速度，这也是赛道的开法。（当然开赛车不是完全匀速过弯，这里面还有很多细节，很粗略地说，就是在直道上减速然后匀速过弯然后出了弯再加速）

对普通司机来说，用油门控制单踏板模式的车，在弯道前减速然后迅速切换到匀速状态，这事还挺难的。
对自动挡油车和不开单踏板模式的电车来说，只要把油门松了，车就会进入到大约匀速的状态（缓慢地减速），所以直接油门刹车都别踩过弯就行，非常容易。

当然了这些都是可以练的技术，高手怎么着都能控制好。对没那么厉害的司机来说，开单踏板模式的车以接近极限的速度过弯确实更困难/危险一些。
这个事有实际的影响，并不是只要减速慢行就完全不会遇到这种情况，因为路上会有意料之外的弯道，弯道里会有意料之外的水或者冰雪。

在深圳为了孩子教育买高价学区房，在我看来有点搞笑了

深圳就不是个教育发达的地方，深圳的价值观是赚钱最重要，实际上不那么在乎教育，这地方遍地是没上过多少学但是很有钱被羡慕的人。
限定在中国的话，显然有教育好得多且房价低得多的地方。
不限定在中国的话，会有教育好更多的地方，房价大概率也不比深圳高。

而且教育是个复杂的事情，又不是买个学区房就能培养出人才了。真要不惜一切代价搞教育的话，买房的好几百万显然有更值得的去处，比如父母先花钱涨点见识。

小时候学数学是真没用，学语言是有用的。

因为存在一些只能在幼儿年龄段获得的语言能力，这些能力决定了一个人能不能把语言学到母语的水平。这也是几乎所有人讲其它语言（不是自己母语的语言）都有口音的原因。
（我当然知道有不少人能把外语说得很好，而且确实是通过努力而不是天赋达到的）

我只是知道有这些事，具体怎么操作应该就比较难了。
我瞎猜一下，如果父母 IELTS 能考到 7 分以上，和孩子一起看英文动画片，应该能让孩子学到接近母语的水平。
但如果父母完全不会英语，只是让孩子自己看英语动画片，我觉得也会有一些作用，有多大就不知道了。

macOS 的 tun 只支持 point-to-point 模式，就是说你要设置一个本机的地址，再设另一个 point 的地址，然后默认情况下只有 dst 是对面地址的 ip packet 会被送到 tun 里面。198.18.0.2 就是设置的那个地址。
这个 tun 的实现挺奇怪的，好像也可以把两个地址设成一样的。
不能 bind .2 的原因很简单，它不是你这台机器的 ip 地址。

“198.18.0.2 在哪里被添加成 HOST 的”
这是 tun 实现的一部分。

这一堆东西基本上就是在折腾 macOS 奇怪的 tun 实现，没什么意思，要真想搞明白就自己写代码创建一个 tun ，然后把路由表改一改看什么情况下会把 dst 哪里的 packet 发给 tun 。Linux 的 tun 就很正常，没这些奇怪的东西。

@lesismal
@yuanmomo

如果真要搞 “高并发”，当然是先初始化好一个实例，后面直接访问。显然这样做可以让后续的操作代价最低，代价最低的方法就是最适合 “高并发” 的方法。
如果初始化很耗时，那就更要提前初始化了，不然一万个请求过来了还得等这个“需要加载很多元数据，很慢” 的初始化。

> 在我看来（我能力有限），其实没有啥性能损失的，最多一点 if 比较，或者如果用枚举的形式实现，我觉得是没有什么性能损失的

和一次简单的 memory load 相比，互斥锁的代价很高。因为互斥锁需要让 CPU 处理非常复杂的缓存一致性问题。https://en.wikipedia.org/wiki/Cache_coherence
当然你可以说这个代价相比读磁盘读网络都可以忽略，那这里的 “高并发” 三个字就多余了。
用枚举来实现当然有一样的代价，不是说你自己没写互斥锁它就没有这个互斥锁，枚举本身当然需要用互斥锁来实现。
如果你觉得用枚举来实现没有性能损失，说明你没想明白这个事到底是怎么实现的，我会觉得你背了一个自己没有理解的答案。

如果你觉得加上 “高并发” 这三个字的意思是说需要使用锁来避免 lazy loading 的 race condition ，那你的理解是错的。对 lazy loading 的情况，加了锁它才是正确的代码，和高并发不相干。

如果想问怎么实现 lazy loading 的单例，其实是这个问题，https://stackoverflow.com/questions/56724421/calling-a-method-only-once-with-multiple-threads

总之这个 “高并发单例” 的问题，本身就挺有问题的。

“那么多种奇技淫巧的归纳总结，全都是屁一样的玩意”
顺便一说这个风格的 Java 用户非常多。

@charlie21
给那个英国人讲讲 施氏食狮史，看看他什么感想。
语言就不是设计出来的，没有什么设计得好不好这一说。
语法很多时候也是给外语学习者用的，尤其是汉语。

举个例子
我刚去吃饭了
我刚去吃了饭
要怎么用语法给外国人解释这两句话的差别？
我估计不少中国人也不能理解这两句的差别
前一句强调 刚才，后一句强调 吃饭

量词的用法其实很好解释，汉语的量词有它的含义。一位盗贼（侠盗），一伙警察（不写了反正是这么个意思），一只马（小马）。如果你不想表达额外的含义，可以全用 个，一个马没什么问题，用“一只马”来表示能骑的马，其实算是用错了。

至于 want to do 和 consider doing ，从上面有人发的 ChatGPT 的回答来看，两个都应该用 to do 才对。它就这么用的，请直接背下来完事

@p1gd0g

深圳香港惠州梅州河源传统上都是客家地区，不是粤语区。
当然后来香港变成了粤语区，深圳变成了普通话区，其它几个还是客家地区