Owen-Zhang

About slice

2

slice可以从一个数组或一个已经存在的slice中再次声明。slice通过array[i:j]来获取，其中i是数组的开始位置，j是结束位置，但不包含array[j]，它的长度是j-i。 看到这个就有点点迷惑了， “j是结束位置，但不包含array[j]，它的长度是j-i”， 为何不包含最后一个数据呢，这个是什么设计哲学？

是否考虑过将 go StartWriter()去掉呢

1

你好，最近看过你的视频，也将源码对照着学习了一下，有一个地方我有点迷惑: 读和写都是一个单独的goroutine去处理, 其中写会依赖 msgBuffChan或者msgChan通道, 现在是一个链接一个写gorutine(也相当于多少个msgBuffChan实例), 链接初始化时：msgBuffChan: make(chan []byte, utils.GlobalObject.MaxMsgChanLen), 如果MaxMsgChanLen设置很大，会占用大量的内存,就相当于一个链接占用一个空屋子(特别是数据交互特别少的时候) 你们是否考虑过使用worker的方式(使用几个goroutine和几个channel将数据write给客户端呢) 个人想法，望指点

关于服务端保存websocket.conn的疑惑

2

保存conn时用到了bucket, 这个在最下层还是使用了map golang中的map有一个很大的问题：delete根本就没有真删除，只是标识了一下,也就是说内存根本就没有free 随着conn的进进出出，长时间运行下去这块内存是不是泄露了呢(内存会慢慢增加)，这只是我的一个疑惑 note: 看map源码, 它实际有一个扩容机制，如果达到扩容条件时，会新建map底层数据(原来的内存就会被free),这样想想好像也不会存在上面的问题 望大哥说说你的想法呢

一点小建议

1

var buf bytes.Buffer _ = pprof.Lookup("xxx").WriteTo(&buf, int(h.opts.DumpProfileType)) 几秒就要运行一次 此处的 buffer是否可以搞成复用呢，不然这样不停的分配，又不停的回收, 这会不会成为性能点， 可能理解的不对

在学习源码的过程中,有一个疑惑： bfe_net/textproto/reader.go 文件中 func (r *Reader) ReadLineBytes() ([]byte, error) { line, err := r.readLineSlice() if line != nil { buf := make([]byte, len(line)) copy(buf, line) line = buf } return...

你提出的新想法中： type API struct { clients map[uint][]*client //我个人感觉这个还可以优化一些 lock sync.RWMutex pingPeriod time.Duration pongTimeout time.Duration upgrader *websocket.Upgrader } //个人想法 type API struct { clients map[uint]*userInfo lock sync.RWMutex pingPeriod time.Duration pongTimeout time.Duration...

发现两个问题： 1. 如果内容为空(什么都没有,包括没有\n\r什么的)，程序会出现死 loop, 如果 if n== 0 { return string(first), nil } 2. 没有对前端有空行(\r\n, \n, \t）这些字节进行处理, 如果前面有空行，返回的第一行数据有问题 3. lastline也有同样的问题 firstline 下面这样怎么样 ``` golang func FirstLine(filename string) (string, error) {...

Service doesn't register to etcd when recovered from network problem or restarting etcd.

1

使用etcd作为注册中心时,如果中间出现网络问题(或者etcd重启)，服务不能重新注册到注册中心