小心服务器内存居高不下的元凶----WebAPI服务

内存这东西虽然便宜，白菜价，但实际在我们的互联网环境中还是非常珍贵的资源，谁叫它不能像硬盘似的，随便弄一块就有好几百G，而没内存就准备挂吧！

话说回来，这次分享的主要是我们在使用调用WebAPI 时的内存竟然居高不下，和解决方法，先上一段代码：

 

using System; using System.Collections.Generic; using System.Net; using System.Net.Http; using System.Net.Http.Formatting; using System.Net.Http.Headers;
namespace EBizClient.Common {     public enum MediaTypeHeader     {         application_json,         application_xml     }     public class HttpClientHelper     {         public MediaTypeHeader mediaType{get;set;}
        public HttpClientHelper(){             this.mediaType = MediaTypeHeader.application_json;         }
        public HttpResponseMessage Get(string url)         {             var client = new HttpClient();             var response = client.GetAsync(url).Result;             return response;         }    

 

        ......     } }

这段代码主要是做了一个简单的封装，方便前端调用WebAPI返回的rest服务,初看是没啥问题，而且挺长一段时间内我们也就这样用了！

突然有一天测试人员告诉我，程序死了，测试机器卡死了，究其原因，在做压力测试的时候内存没了，但“释压”以后，依然霸占着内存不肯放，只能硬重启。这可是个大问题，我们就这样重复试验，每次结果都一样，去“压”哪个服务，那个服务的IIS进程占用内存就只进不出了。根据这种场景，我们定位问题要么在数据访问层（可能性不大，我们用了比较成熟的框架），要么就是在数据缓存逻辑那边出了问题（但监测下来存在缓存中的数据少的可怜啊）。

 

折腾了一段时间，静下心来，分析问题发觉我们根本就是找错了方向，一个同事提醒会不会是web服务一直占用着没有释放呢？在“重压”之下，有些服务无法得到及时响应，但自己又不会释放，越积越多，形成当前局面，从这个思路下手，修正一下代码：

 

 public HttpResponseMessage Get(string url)         {             var client = new HttpClient();             HttpResponseMessage response = null;             client.GetAsync(url).ContinueWith(              (requestTask) =>              {                  response = requestTask.Result;
             }).Wait(60000);             return response;         }

这段代码就是在其异步调用服务的时候给一个响应时间，如果这个服务1分钟都没有响应，则自动停止释放掉，到此，这个郁闷的问题就被解决了！

这也是采用新框架尤其需要谨慎的地方，这个问题的解决虽然带有一定的偶然性，但如果真正了解http协议的本源（最基础的无非就是request和response到底是怎么一回事），其实解决它也应该是个必然的结果！

 

路漫漫而修远，吾将上下而求索~~