内存这东西虽然便宜，白菜价，但实际在我们的互联网环境中还是非常珍贵的资源，谁叫它不能像硬盘似的，随便弄一块就有好几百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到底是怎么一回事），其实解决它也应该是个必然的结果！

 

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