主要还是得考虑跨线程时怎么处理

这次的情况，无论是 mapped without write access 还是 mapped PROT_NONE 亦或者是 unmapped addresses ，如果按照上文引用的段落来看，都应该是 SIGSEGV

@lslqtz

@lslqtz 至于 Mac 是否 POSIX 兼容，这我确实不清楚了，我记得好像 Windows 也说自己 POSIX 兼容来着，也确实针对 POSIX 做了一些工作，但我就不太了解了。

@lslqtz 关于这个，我查阅了下参考，不确定引用的段落是否正确，欢迎指正：
> Memory Protection
>
> When an object is mapped, various application accesses to the mapped region may result in signals. In this context, SIGBUS is used to indicate an error using the mapped object, and SIGSEGV is used to indicate a protection violation or misuse of an address:
> - A mapping may be restricted to disallow some types of access.
> - Write attempts to memory that was mapped without write access, or any access to memory mapped PROT_NONE, shall result in a SIGSEGV signal.
> - References to unmapped addresses shall result in a SIGSEGV signal.
> - Reference to whole pages within the mapping, but beyond the current length of the object, shall result in a SIGBUS signal.
> - The size of the object is unaffected by access beyond the end of the object (even if a SIGBUS is not generated).

---- The Open Group Base Specifications Issue 7, 2018 Edition
https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_08_03_03

@lslqtz 这 POSIX 里的，怎么就不承诺了😰，这还叫遵守 POSIX 规范？

这个取决于你的规模吧，重点是如果你实践微服务模式，那数据库从逻辑上一定要分开。部署在不在一起就看规模吧。

早期语言很多都不是从 0 开始的，可能 C 开了个头？人家有指针，按 offset 的思路走很正常

@foam 其实还有个事，index 往往是个 i 或者 ui ，从 1 开始就浪费一个

可能是因为他们想用这个数字表示 offset 吧，那开头的那个 offset 可不就是 0 呗。如果你的程序也是按 offset 这套思路走，那还是挺舒服的。

这种东西，开发者如果不诚实，怕是用的人心里也要打个问号哟🥰

如果你真的希望服务器远离用户口令明文，那不得不采用更复杂的方案，比如说采用某种公钥算法，以用户的口令加密私钥，私钥不离开用户的电脑，服务器只用过挑战响应来实现对用户的认证。

首先，口令应使用专用的哈希算法，bcrypt argon 这种，而不是随便 md5 一下，至少也应该按照有关 RFC 的要求迭代+padding+hash 。
考虑 md5 这种简单的 hash 是否潜在地缩小了用户口令的值域。此外如果你无法在前端完成正确的口令哈希过程，该 hash 的泄漏和用户口令泄漏没什么实质性区别。

不需要在什么地方用 Java 什么地方用 Kotlin 制定繁琐的细则，如果你的团队能够把 Kotlin 用好，成员自己一定清楚该怎么做。

Kotlin 现在最大的问题一个是语法和标准库特性不够激进，Java 也在更新迭代，另一个是工具链质量比较差，生成的字节码相对糟糕一点。
不过后者好在有 JVM 的 JIT 加持，除了一些边边角角（比如 vararg 展开）并不会产生多少实际影响。
综合考虑 Java 和 Kotlin 现状，我建议可以将大部分业务代码用 Kotlin 编写，在一些明显用 Kotlin 写起来更繁琐的地方，不要犹豫，直接用 Java 写。
会 Kotlin 的开发者熟悉 Java 几乎是必须的。

随便发起私聊了？

@felixlong apple 这个只是一个很 corner case 的场景，到不好说会不会改回去，也许就让大家吃了。

@Rorysky 如果利用捕获 sigsegv 去做某些事是错误的，那设计这个信号量又是为了什么？如果你说有些事可以做有些事不能做，那就得讲明白哪些事不能做，有什么合理的理由。

@Rorysky
> Null checks are cheap. They usually fold straight into a related memory access instruction, and use the CPU bus logic to catch nulls. (Deoptimization follows, with regenerated code containing an explicit check.)

@Rorysky 信号量怎么就不是一个特性了？这都是写在文档上的，就因为它预期中不常见，所以就不是个特性从而可以随便更改了？既然承诺了它所产生的效果和副作用，怎么就不能用于优化了？实际上因为这个动作的延迟相对较高，JVM 的 JIT 也是用来做非预期分支去优化判定的。
一个东西既然承诺了效果，那就不该去干涉使用者怎么用，除非你有合理的理由，提前注明。