• 请不要在回答技术问题时复制粘贴 AI 生成的内容
aliipay
V2EX  ›  程序员

又遇到考试般的面试题(golang)

  •  
  •   aliipay · Sep 2, 2019 · 7152 views
    This topic created in 2622 days ago, the information mentioned may be changed or developed.
    问题如下:
    1. golang 什么情况下会 panic
    2. 使用 map 时候要注意什么
    在不查资料情况下各位能答出几点?

    面试时第一个问题回答了 5 点。第二个问题回答了 1 点[尴尬脸]。
    事后查资料发现者两个问题都有装逼方式回答:一种或者无数种情况
    16 replies  •  2020-03-16 17:44:47 +08:00
    mengzhuo
    mengzhuo
    Sep 2, 2019❤️3
    1
    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,所以不用在意性能
    aliipay
    aliipay
    OP
    Sep 2, 2019❤️2
    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 性能问题
    mengzhuo
    mengzhuo
    Sep 2, 2019
    3
    @aliipay
    1. 当然可以,写错代码的时候就有,我开发 Go 的时候经常见
    2. 好, 不算,不过业务最常见的 crash 就是它了
    3. 不,你试试函数里调函数本身,stack 大小超过 1G 就会 stack overflow
    4. 汇编是基础,你运行的每一行 Go 语句背后都有机器码支撑的。再说你想你在三星手机上一用 atomic 就挂什么体验。
    5. 系统调用返回值不正确也会引起 panic,可以看 Go 的 issue 列表。
    gamexg
    gamexg
    Sep 2, 2019
    4
    @aliipay #2 碰到过 OOM
    linux 系统内存不足,查日志并没发现被系统 kill,而是 go 程序申请内存失败,然后 panic 了。
    frozenshadow
    frozenshadow
    Sep 2, 2019
    5
    我被问道一个综合了 golang 传值方式,golang 汇编,defer 的问题:defer 影响命名返回值的原理。

    https://timelife.me/index.php/archives/163/ 只简单打了注释,还没时间写详细过程,凑合看吧
    aliipay
    aliipay
    OP
    Sep 2, 2019
    6
    @mengzhuo
    我对题目的理解是 golang 的 panic 而不是其它任何形式的 crash,后者范围很大,前者只和语言相关。(区分这可能有点转牛角尖,对实际工作用处不大)

    函数里调函数本身 这个没能重现出"stack overflow"。go version 1.11.2 linux/amd64。
    goroutine stack 是放用的进程 heap 里面,受系统内存影响,所以出现的是"out of memory" 。 这个也算 panic 的话,一直 make 也会出现。。。
    aliipay
    aliipay
    OP
    Sep 2, 2019❤️1
    7
    @frozenshadow
    defer 问题确实是个烂坑,目前来看得出结果基本没啥问题, 原理是不太懂,因为不懂汇编。
    推荐 advanced-go-programming 这本书,里面有讲到 defer 的问题
    sagaxu
    sagaxu
    Sep 3, 2019 via Android
    8
    @aliipay 个人觉得,看汇编代码有局限性,asm 只能验证结果的产生逻辑,却不能证明它,因为并没有解释为何会生成这种 asm。从 lang spec 出发,根据各种条款推导论证出结果的必然性,是更严谨的做法。
    reus
    reus
    Sep 3, 2019❤️1
    9
    6ufq0VLZn0DDkL80
    6ufq0VLZn0DDkL80
    Sep 3, 2019
    10
    好无聊的问题。我就提一点,非要抠的话,fatal 和 panic 也是不同的,很多前面提到的比如 stack overflow 都是 fatal,不是 panic,fatal 是没法 recover 的。
    zarte
    zarte
    Sep 3, 2019
    11
    1.也就数组越界这个容易出现,其他编译的时候就能搞定了。
    2.除了是地址引用这点还有别的?
    frozenshadow
    frozenshadow
    Sep 3, 2019 via Android
    12
    @aliipay 这本书里也有一些汇编入门的 :)
    stevenbipt
    stevenbipt
    Sep 3, 2019
    13
    第一个问题个人遇到过数组越界和并发竞态导致了 panic
    第二个问题遇到过一个特别好玩的坑,当字段为引用类型的时候(比如结构体),没办法修改字段内的成员变量; map 的并发问题在 go 里面呢也非常常见
    aliipay
    aliipay
    OP
    Sep 3, 2019
    14
    @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
    等等
    这些都是编译时候判断不出的
    DelayNoMay
    DelayNoMay
    Mar 16, 2020
    15
    @mengzhuo 汇编的出错肯定是不算在 golang 的 panic 里面的,要是算的话,为什么不算在 c++里面呢?
    mengzhuo
    mengzhuo
    Mar 16, 2020
    16
    @DelayNoMay 怎么不算?跟语言都没关系,其他没有 runtime 的直接 core 给你看
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Privacy   ·   Solana   ·   932 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 43ms · UTC 20:10 · PVG 04:10 · LAX 12:10 · JFK 15:10
    ♥ Do have faith in what you're doing.