面试问题总结（一）Golang

Posted 2023-04-23

参考技术A

使用go语言的好处: go语言的设计是务实的, go在针对并发上进行了优化, 并且支持大规模高并发, 又由于单一的码格式, 相比于其他语言更具有可读性, 在垃圾回收上比java和Python更有效, 因为他是和程序同时执行的.

1. 进程, 线程, 协程的区别, 协程的优势

2. 讲一下GMP模型(重点)

3. Go的GC, 混合写屏障(重点)

4. go的Slice和数组的区别, slice的扩容原理(重点)

5. 讲一下channel,实现原理(重点)

6. 讲一下Go的Map的实现原理, 是否线程安全, 如何实现安全(重点)

7. new 和 make 的区别

8. 说一下内存逃逸

9. 函数传指针和传值有什么区别

10. goroutine之间的通信方式

11. 测试是怎么做的(单元测试, 压力测试)

12. 堆和栈的区别

golang websocket总结（问题贴）

因为工作的需要，接触了websocket，开始的一些很简单的代码，都不知道该怎样运行起来，所以，总是有一层神秘感，却没有太多的兴趣去研究它。不过，还是免不了要了解一些才不至于对于后续的工作有影响。从塌下心来学习，到最后完成编码测试，不超过一周，遇到了很多问题，万幸，通过自己的思考和师傅们帮忙都解决了。

       关于go与websocket编程，github上有很多开源的源码，比如https://github.com/garyburd/go-websocket。我发现，现在网上流传的关于go 的websocket编程基本上都是差不多的类型，当然，websocket也不过如此而已啦。再说说，对如此简单的问题，我碰到的那些麻烦事吧。

      1.当服务器启动起来之后，再怎么运行？因为刚开始对websocket的认识都是一知半解的，连程序怎样运行起来都不知道。开始是直接运行html文件，只是静态页面，貌似根本就没有跟服务器进行互动一样。想了想，直接在浏览器中输入ip，竟然好了，这才明白服务器中指定url的意义。

      2.因为工作需要，我们的开发都是在虚拟机内进行的，可是虚拟机上不能连外网的。自己觉得还是脱离虚拟机用起来更爽些，所以，不辞劳苦地每天早上早来把环境部署好，就是为了当天可以在外网环境中工作，这是多么大无畏的精神啊，嘿嘿。言归正传，在外网运行好好的程序，迁移到内网的时候却怎样都运行不起来了。这个原因也是很容易找的，因为内网和外网只有一个区别，一个能上外网，一个不能。看了下代码，是有src="http://ajax.googleapis.com/ajax/libs//1.4.2/jquery.min.js"，所以，这些js资源应该是在网上下载下来的，我把这个库下载下来保存到文件，通过src将资源关联进来，竟然还不行。同样的操作，我在外网又弄了一遍，也是运行部起来。以前学过一些浏览器调试的方法，发现根本就找不到这些源文件，目录都是好好的，怎么就是找不到呢？真是让人郁闷了。把师父叫过来，他说找不到资源，然后把websocket的原理又给我讲了一遍，这些协议什么的以前接触太少了，好多时候不是一下子就能明白过来的。说在浏览器中输入ip时，会从这个目录下去找，当然找不到了。然后说开启nginx什么的，反正我没听懂。既然只能找到这个html文件，我为何不能把这些js文件内容都直接写到html中呢？事实证明，这个想法还是不错的，因为js代码都比较集中，不会影响代码的可读性。

    3.关于协议中信息的传输，很重要的一点是，要统一两端的数据格式。我的想法就是拿到原原本本从对端传来的数据，根据自己的需要进行封装。这样两边都是以byte数组进行传递的。可是，server端接收到数据之后，为了验证正确性，我把它转换为字符串打印出来，也奇了怪了，只要是一转换，就只能打印出第一次接收的数据，后面的好像都被丢掉了一样。如果不转换，就可以一条不少地把信息的二进制流打印出来。我把所有会出错的地方都扫了一遍，并不觉得哪里会有问题啊。我又把师父给叫来了。把我的情况描述了下，他给我的建议是，尽量使用websocket包已经封装好的函数，这样一方面性能上有保证，另一方面也可以减少出错的几率。我当时还是很纠结为什么会出现这样的结果，所以即使是将自己的函数替换为函数库中的函数，总不忘去试一下会不会转换时候还是有问题。为了调试方便，把所有的输入到重定向了文件，然后通过文本编辑器看结果。这次，还是同样的结果，这说明我的代码可能不是导致出现问题的源头。我把输出尽量减少，在编译器中直接运行，竟然看到了正确的结果，我确认，出问题的是文本编辑器，真是不靠谱啊，害得我花了一下午的时间来找问题。后来也碰到了类似的问题，所有的输出在文本编辑器中竟然都成了一串串的数字，实用cat打印，内容是正常的。不自己冒出一句话，这开源的真是不靠谱啊。当然，现在不会再那么依赖文本编辑器了，其实已经换了三个了，总会时不时出现恼人的bug。

 4.关于代码的组织结构方面，我觉得不太可能的事情都被师父一句话给解决了，真是佩服得我五体投地啊。有些时候，把一些功能封装到一个函数中，再进行调用，可以使代码看起来比较整洁，我就犯了这个毛病，总是想着把那些功能封装起来，直接一调用，很方便。关于将函数嵌入到内部，倒是见过，自己从来都没有用过，现在遇到问题，也不可能想到可以那样解决啊。所以，这也算又是一个经验吧。

5.中文乱码问题。对于学的人来说，中文乱码好像是老生常谈的问题，不管你怎么小心翼翼，这个中文乱码总是阴魂不散。以前，每次遇到乱码，就会抱怨自己，怎么就选择了java了呢，这不是没事找事吗？现在好不容易脱离java了，竟然同样遇到了中文乱码。我竟然跟师傅讨价还价，我们可以不支持中文啊，干嘛非要花力气去解决这个问题。他当时脸都绿了，说这个必须有啊。现在想想，自己真是挺搞笑的，怎么这么容易就退缩了呢。使用英文的时候，tcp和websocket互相通信都是好的，唯有在websocket浏览器客户端输入中文时候就乱码了。跟踪了很久，发现从浏览器中发出，到从服务器往外发送都是正确的中文，只有到浏览器接收到数据之后就成了乱码了。我就把问题归结为，js代码中字符编码是不是有问题呢？当时并没有觉得自己的服务器发送端是有问题的，因为即使是websocket间使用程序通信，中文也是没有问题的。找来以前的师父，他再三问我确认服务器端发送时候是正常的吗，开始我说确定，后来被他问蒙了，变成了应该没问题吧。他就开始找前端的问题。说按理说前端代码都是自适应的，不应该调整字符编码，要不然用户体验就差了，谁因为访问个网页还去修改字符集啊。最后得出的结论是，浏览器收到消息时候已经是乱码了。这就不好玩了，这充分说明问题是出在发送端的，那为什么不用浏览器就是好的呢？用原来的demo程序运行，发现中文是可以的，找了下，原来我发送的时候都是把消息转换成了byte数组，其实直接按照string格式的数据传递给函数就可以了。也许函数内部已经将这些数据进行了重新转换了吧。

     这几个应该是纠缠我时间最长的问题，通过解决这些问题，自己也学会了很多东西。遇到问题能够静下心来分析了。