首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  程序员

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

  •  
  •   aliipay · 48 天前 · 2837 次点击
    这是一个创建于 48 天前的主题,其中的信息可能已经有所发展或是发生改变。
    问题如下:
    1. golang 什么情况下会 panic
    2. 使用 map 时候要注意什么
    在不查资料情况下各位能答出几点?

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

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

    函数里调函数本身 这个没能重现出"stack overflow"。go version 1.11.2 linux/amd64。
    goroutine stack 是放用的进程 heap 里面,受系统内存影响,所以出现的是"out of memory" 。 这个也算 panic 的话,一直 make 也会出现。。。
        7
    aliipay   48 天前   ♥ 1
    @frozenshadow
    defer 问题确实是个烂坑,目前来看得出结果基本没啥问题, 原理是不太懂,因为不懂汇编。
    推荐 advanced-go-programming 这本书,里面有讲到 defer 的问题
        8
    sagaxu   48 天前 via Android
    @aliipay 个人觉得,看汇编代码有局限性,asm 只能验证结果的产生逻辑,却不能证明它,因为并没有解释为何会生成这种 asm。从 lang spec 出发,根据各种条款推导论证出结果的必然性,是更严谨的做法。
        9
    reus   48 天前
        10
    cholerae   48 天前
    好无聊的问题。我就提一点,非要抠的话,fatal 和 panic 也是不同的,很多前面提到的比如 stack overflow 都是 fatal,不是 panic,fatal 是没法 recover 的。
        11
    zarte   47 天前
    1.也就数组越界这个容易出现,其他编译的时候就能搞定了。
    2.除了是地址引用这点还有别的?
        12
    frozenshadow   47 天前 via Android
    @aliipay 这本书里也有一些汇编入门的 :)
        13
    stevenbipt   47 天前
    第一个问题个人遇到过数组越界和并发竞态导致了 panic
    第二个问题遇到过一个特别好玩的坑,当字段为引用类型的时候(比如结构体),没办法修改字段内的成员变量; map 的并发问题在 go 里面呢也非常常见
        14
    aliipay   47 天前
    @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
    等等
    这些都是编译时候判断不出的
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   744 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 24ms · UTC 21:12 · PVG 05:12 · LAX 14:12 · JFK 17:12
    ♥ Do have faith in what you're doing.