问题场景：高频系统中，agent 会向ATS 服务器发出刷新和预缓存的请求，这里的请求head 里面有GET ，PURGE等，因为一般的预缓存都是小文件，但是某天，突然服务器oom。。。罪魁祸首发现是并发GET 大文件将服务器打死了。第一个版本是python 的，第二个版本是golang 实现的， 这里记录下两种语言的 下载大文件的实现方式。

    第一种是python，使用的是request 库, 使用流式读取的方式，写到空设备中去。

res = self.session.request(method, url, data=body, headers=header, timeout=timeout, proxies=proxies, stream=True) with open("/dev/null", 'wb') as f:             for chunk in res.iter_content(chunk_size=1024):                 if chunk: # filter out keep-alive new chunks                     f.write(chunk)                     f.flush() 

    第二种方式，对于golang ，使用io.Copy(), 将response copy 到空设备中。

func downLoadFile(url string)(len int, err error){ 	//err write /dev/null: bad file descriptor# 	out, err := os.OpenFile("/dev/null", os.O_RDWR|os.O_CREATE|os.O_APPEND, 0666) 	defer out.Close() 	resp, err := http.Get(url) 	defer resp.Body.Close() 	n, err := io.Copy(out, resp.Body) 	return n, err }

    使用这种方式为什么不会出现oom 的情况？因为两个原因，第一个， resp.Body 只是个reader 并没有发生真实的读取操作，第二个是io.copy 这个函数设置了缓冲区大小限制为3m，不会一次全部读取到内存中，下面是标准库的源码：

func Copy(dst Writer, src Reader) (written int64, err error) { 	return copyBuffer(dst, src, nil) }  // copyBuffer is the actual implementation of Copy and CopyBuffer. // if buf is nil, one is allocated. func copyBuffer(dst Writer, src Reader, buf []byte) (written int64, err error) { 	// If the reader has a WriteTo method, use it to do the copy. 	// Avoids an allocation and a copy. 	if wt, ok := src.(WriterTo); ok { 		return wt.WriteTo(dst) 	} 	// Similarly, if the writer has a ReadFrom method, use it to do the copy. 	if rt, ok := dst.(ReaderFrom); ok { 		return rt.ReadFrom(src) 	} 	if buf == nil { 		buf = make([]byte, 32*1024) //这一步可以控制每次缓冲区迭代的大小，默认大小是3m 	} 	for { 		nr, er := src.Read(buf) 		if nr > 0 { 			nw, ew := dst.Write(buf[0:nr]) 			if nw > 0 { 				written += int64(nw) 			} 			if ew != nil { 				err = ew 				break 			} 			if nr != nw { 				err = ErrShortWrite 				break 			} 		} 		if er != nil { 			if er != EOF { 				err = er 			} 			break 		} 	} 	return written, err }