这是一个创建于 1909 天前的主题，其中的信息可能已经有所发展或是发生改变。
问题如下：
1. golang 什么情况下会 panic
2. 使用 map 时候要注意什么
在不查资料情况下各位能答出几点？
面试时第一个问题回答了 5 点。第二个问题回答了 1 点[尴尬脸]。
事后查资料发现者两个问题都有装逼方式回答：一种或者无数种情况
1. golang 什么情况下会 panic
2. 使用 map 时候要注意什么
在不查资料情况下各位能答出几点？
面试时第一个问题回答了 5 点。第二个问题回答了 1 点[尴尬脸]。
事后查资料发现者两个问题都有装逼方式回答：一种或者无数种情况
 |
1
mengzhuo 2019-09-02 21:22:59 +08:00  3
1. 海了去了……
内存越界类：slice 越界、访问未初始化对象、segment fault、PC address invalid 内存不足类：OOM、stack overflow CPU 问题： 执行到 CPU 无法识别的指令（三星的 CPU 哈哈哈），跳转地址超过 CPU 的上限，qemu 里各种诡异的问题 操作系统：signal fault，syscall invalid （用 WSL ） 杂类：goroutine dead lock，错误的 type assert， 2.1 不要并发写 2.2 Go 的函数是值传递，但是 map 又是指针类型，所以函数间 map 复用的时候也要小心 2.3 map 是每个的 seed 都不同 deepcopy 只能挨个复制，不能拷贝 map 数据体 2.4 SSA 会优化遍历 delete，所以不用在意性能 |
 |
2
aliipay OP 2
@mengzhuo 确实可以海了去了，但是几点问题：
1.1 golang 你能制造出"segment fault、PC address invalid" 吗？ 除了调用其它语言和者使用 unsafe 模块 1.2 OOM 是操作系统行为，不是 panic 1.3 stack overflow 我个人认为也是操作系统触发的 1.4 据我所知没法直接调用 cpu 指令，除非嵌入汇编， 这种错误明显不算在 golang panic 1.5 操作系统的错误都不算，要的是 golang 的 panic 2.1 这个是个问题， 准确的说是并发读写要加锁。 因为以前是写 C++的，默认这个是基本操作，当时没答这点 2.2 嗯。。。 2.3 刚学的时候看到过，不过业务代码重来没有到过 2.4 SSA 确实不了解，不过线上同样没遇到过 delete 性能问题 |
|
3
mengzhuo 2019-09-02 22:29:35 +08:00
@aliipay
1. 当然可以，写错代码的时候就有，我开发 Go 的时候经常见 2. 好, 不算，不过业务最常见的 crash 就是它了 3. 不，你试试函数里调函数本身，stack 大小超过 1G 就会 stack overflow 4. 汇编是基础，你运行的每一行 Go 语句背后都有机器码支撑的。再说你想你在三星手机上一用 atomic 就挂什么体验。 5. 系统调用返回值不正确也会引起 panic，可以看 Go 的 issue 列表。 |
 |
4
gamexg 2019-09-02 22:34:33 +08:00
@aliipay #2 碰到过 OOM
linux 系统内存不足，查日志并没发现被系统 kill，而是 go 程序申请内存失败，然后 panic 了。 |
 |
5
frozenshadow 2019-09-02 22:38:58 +08:00
我被问道一个综合了 golang 传值方式，golang 汇编，defer 的问题：defer 影响命名返回值的原理。
https://timelife.me/index.php/archives/163/ 只简单打了注释，还没时间写详细过程，凑合看吧 |
|
6
aliipay OP @mengzhuo
我对题目的理解是 golang 的 panic 而不是其它任何形式的 crash，后者范围很大，前者只和语言相关。（区分这可能有点转牛角尖，对实际工作用处不大） 函数里调函数本身 这个没能重现出"stack overflow"。go version 1.11.2 linux/amd64。 goroutine stack 是放用的进程 heap 里面，受系统内存影响，所以出现的是"out of memory" 。 这个也算 panic 的话，一直 make 也会出现。。。 |
|
7
aliipay OP 1
@frozenshadow
defer 问题确实是个烂坑，目前来看得出结果基本没啥问题， 原理是不太懂，因为不懂汇编。 推荐 advanced-go-programming 这本书，里面有讲到 defer 的问题 |
 |
8
sagaxu 2019-09-03 01:38:22 +08:00 via Android
@aliipay 个人觉得，看汇编代码有局限性，asm 只能验证结果的产生逻辑，却不能证明它，因为并没有解释为何会生成这种 asm。从 lang spec 出发，根据各种条款推导论证出结果的必然性，是更严谨的做法。
|
 |
9
reus 2019-09-03 01:42:41 +08:00 1
|
 |
10
cholerae 2019-09-03 02:13:39 +08:00
好无聊的问题。我就提一点，非要抠的话，fatal 和 panic 也是不同的，很多前面提到的比如 stack overflow 都是 fatal，不是 panic，fatal 是没法 recover 的。
|
 |
11
zarte 2019-09-03 10:20:50 +08:00
1.也就数组越界这个容易出现，其他编译的时候就能搞定了。
2.除了是地址引用这点还有别的？ |
|
12
frozenshadow 2019-09-03 11:19:10 +08:00 via Android
@aliipay 这本书里也有一些汇编入门的 ：）
|
 |
13
stevenbipt 2019-09-03 14:25:17 +08:00
第一个问题个人遇到过数组越界和并发竞态导致了 panic
第二个问题遇到过一个特别好玩的坑，当字段为引用类型的时候（比如结构体），没办法修改字段内的成员变量； map 的并发问题在 go 里面呢也非常常见 |
|
14
aliipay OP @zarte
goroutine dead lock， mutex dead lock error type assert map slice 等空指针 make slice len/cap out of range integer divide by zero integer overflow invalid memory address or nil pointer dereference channel： make chan size out of rang send on closed channel close of nil channel close of closed channel 等等 这些都是编译时候判断不出的 |
 |
15
DelayNoMay 2020-03-16 16:45:00 +08:00
@mengzhuo 汇编的出错肯定是不算在 golang 的 panic 里面的，要是算的话，为什么不算在 c++里面呢？
|
|
16
mengzhuo 2020-03-16 17:44:47 +08:00
@DelayNoMay 怎么不算？跟语言都没关系，其他没有 runtime 的直接 core 给你看
|
Select Language