返回信息流多谢各位！ 怪我没有说的清楚，我在原代码段再添加一些上下文哈
------------------------------------
各位大神，有个问题想请教下：
场景：服务器接收请求后的某函数中：
```
func f2() (m map[int][]byte) {
resultmap = f1() // >>>>>>>> #FIRST
m = make(map[int][]byte)
for k,v := range resultmap{
someint := Somefunc(k)
m[someint] = v
delete(resultmap, k)
}
return
}
func f1() (m map[string][]byte){
data := make([]byte,100) // >>>>>>>>> #SECOND
DoSomething(data) // fill data here
m = make(map[string][]byte)
fname := string(data[0:50])
fdata := data[50:100]
m[fname] = fdata
return m
}
```
f2() 返回的map会在beego中SetSession存储，每一次新的client连接都会请求一次map，即使client关闭也需要较长时间才能释放。
所以好像也可能和session有关？ 不过pprof没有提到session。。。 pprof调用weblist相关函数之后显示#FIRST和#SECOND两处内存占用较高。
在这个条件下m中的key和value都是data这个slice的slice，而在所有请求执行完毕后，这个m没有被释放，导致了服务器内存占用居高不下，需要很长时间才能释放m，pprof后看到问题出现在这个data:=make([]byte,100)上。
想问下，这种slice再slice，然后存到map的key-value中的场景，有什么好办法可以使内存尽快释放呢？
多谢各位～
这是一条镜像帖。来源：北邮人论坛 / golang / #1424同步于 2019/4/23
该镜像源已超过 30 天没有更新，可能在源站已被删除。
Golang机器人发帖
GO中slice与map的内存释放方案
ZzZ2251
2019/4/23镜像同步5 回复
订阅后，新回复会通过你的通知中心匿名送达。
5 条回复
给的信息比较少，只能按照常规分析下
楼主的情况主要原因是在单个请求结束后，该请求的m没有及时释放，导致m关联的fdata没有释放，而fdata实际是data的一个片段，所以最终引起的就是data没有释放，pporf看到的就是data:=make([]byte,100)申请的内存很大。
而m没有及时释放可能的原因是gc，gc只有在对象不再被引用后的几分钟后才开始清除对象
所以，一个解决办法是内存复用，把m的所有value都管理起来（比如sync.Pool)，请求结束时回收
多谢～
请问这种情况下，如何解决并发访问和修改的问题呢？
【 在 gaoweiwei 的大作中提到: 】
: 给的信息比较少，只能按照常规分析下
: 楼主的情况主要原因是在单个请求结束后，该请求的m没有及时释放，导致m关联的fdata没有释放，而fdata实际是data的一个片段，所以最终引起的就是data没有释放，pporf看到的就是data:=make([]byte,100)申请的内存很大。
: 而m没有及时释放可能的原因是gc，gc只有在对象不再被引用后的几分钟后才开始清除对象
: ...................