面向服务架构~本地轮训服务占用内存过高的问题

简介:

对于WEB程序来说,它寄宿在IIS提供的w3wp进程中,这个进程占用的内存大小和你的应用程序的使用有个直接关系,你的程序写的标准,它占用内存就相对低,你的程序写的伪范规,该释放的东西不让系统释放(有些对象GC回收不了),就会造成内存使用过高的情况,对于32位系统来说,最高1.6G,超过后,进程自动挂掉!

对于本地服务来说,一般我们采用windowService,windowform来承载,它会自己有一个进程,而最近,我的windowService占用内存过高的问题真的出现了,不到5分钟,进程已经达到500多兆了,而且还在处理递增长的趋势,当我们review代码后,发现了一个大问题,看下面代码您是否也发现了呢,代码里的坏味道

   public class User_SendMessageJob : JobBase, IJob
    {
        private static object lockObj = new object();
        private object IBigRepository = new object();
        public void Execute(IJobExecutionContext context)
        {
            lock (lockObj)
            {
                #region 需要处理的任务
                //Logger.Info(context.JobDetail.Key.Name + DateTime.Now);
                #endregion
            }
        }
    }

上面的代码,声明了两个全局变量lockObj和IBigRepository,其中这个IBigRepository在方法Execute被调用,并用是轮训调用,为了避免并发冲突,采用了lock进行排它锁的设计,当这个全局对象本应该在程序运行结束后,就被释放,但是,我们去想,如果线程1正在执行lock里的代码,而线程2这种由于轮训服务,也开始进入方法,这时IBigRepository对象没有被释放,线程2又产生了一个新的对象,这时,我们的IBigRepository对象就越来越多,导致你的内存消耗越来越大!

正确的作法应该是,将IBigRepository对象声明在Execute方法里,作为局部变量,当lock结束后,就会被系统自动加收,下一个线程2进来后,才会建立新的IBigRepository对象,这样,我们就保存了,在轮训服务中,始终只有一个IBigRepository对象被建立,这种设计才是正确的.

看一下修改后的代码

 public class User_SendMessageJob : JobBase, IJob
   {
        private static object lockObj = new object();
        public void Execute(IJobExecutionContext context)
        {
            lock (lockObj)
            {
                object IBigRepository = new object();

                #region 需要处理的任务
                //Logger.Info(context.JobDetail.Key.Name + DateTime.Now);
                #endregion
            }
        }
   }

在修改了程序之后,再看一下内存,只有200M,而且没有递增的趋势,这才是正确的程序,所以说,有些基础知识很重要,我们不应该去忽视它,就像老赵说过一句话:学好操作系统才能写出好的windows程序,学习IIS运行机制,才能写出好的WEB程序!

本文转自博客园张占岭(仓储大叔)的博客,原文链接:面向服务架构~本地轮训服务占用内存过高的问题,如需转载请自行联系原博主。

目录
相关文章
|
5月前
|
消息中间件 负载均衡 中间件
⚡ 构建真正的高性能即时通讯服务:基于 Netty 集群的架构设计与实现
本文介绍了如何基于 Netty 构建分布式即时通讯集群。随着用户量增长,单体架构面临性能瓶颈,文章对比了三种集群方案:Nginx 负载均衡、注册中心服务发现与基于 ZooKeeper 的消息路由架构。最终选择第三种方案,通过 ZooKeeper 实现服务注册发现与消息路由,并结合 RabbitMQ 支持跨服务器消息广播。文中还详细讲解了 ZooKeeper 搭建、Netty 集群改造、动态端口分配、服务注册、负载均衡及消息广播的实现,构建了一个高可用、可水平扩展的即时通讯系统。
537 0
|
5月前
|
文字识别 运维 监控
架构解密|一步步打造高可用的 JOCR OCR 识别服务
本文深入解析了JOCR OCR识别服务的高可用架构设计,涵盖从用户上传、智能调度、核心识别到容错监控的完整链路,助力打造高性能、低成本的工业级OCR服务。
234 0
架构解密|一步步打造高可用的 JOCR OCR 识别服务
|
运维 监控 负载均衡
动态服务管理平台:驱动微服务架构的高效引擎
动态服务管理平台:驱动微服务架构的高效引擎
246 17
|
运维 监控 负载均衡
探索微服务架构下的服务治理:动态服务管理平台深度解析
探索微服务架构下的服务治理:动态服务管理平台深度解析
|
运维 监控 安全
探索微服务架构下的服务治理:动态服务管理平台的力量
探索微服务架构下的服务治理:动态服务管理平台的力量
|
存储 前端开发 Java
Kotlin教程笔记 - MVVM架构怎样避免内存泄漏
Kotlin教程笔记 - MVVM架构怎样避免内存泄漏
165 2
|
Cloud Native Java API
聊聊从单体到微服务架构服务演化过程
本文介绍了从单体应用到微服务再到云原生架构的演进过程。单体应用虽易于搭建和部署,但难以局部更新;面向服务架构(SOA)通过模块化和服务总线提升了组件复用性和分布式部署能力;微服务则进一步实现了服务的独立开发与部署,提高了灵活性;云原生架构则利用容器化、微服务和自动化工具,实现了应用在动态环境中的弹性扩展与高效管理。这一演进体现了软件架构向着更灵活、更高效的方向发展。
|
存储 前端开发 Java
Android MVVM架构模式下如何避免内存泄漏
Android采用MVVM架构开发项目,如何避免内存泄漏风险?怎样避免内存泄漏?
379 1
|
8月前
|
存储 NoSQL Redis
阿里面试:Redis 为啥那么快?怎么实现的100W并发?说出了6大架构,面试官跪地: 纯内存 + 尖端结构 + 无锁架构 + EDA架构 + 异步日志 + 集群架构
阿里面试:Redis 为啥那么快?怎么实现的100W并发?说出了6大架构,面试官跪地: 纯内存 + 尖端结构 + 无锁架构 + EDA架构 + 异步日志 + 集群架构
阿里面试:Redis 为啥那么快?怎么实现的100W并发?说出了6大架构,面试官跪地: 纯内存 + 尖端结构 +  无锁架构 +  EDA架构  + 异步日志 + 集群架构
|
9月前
|
消息中间件 人工智能 监控
文生图架构设计原来如此简单之分布式服务
想象一下,当成千上万的用户同时要求AI画图,如何公平高效地处理这些请求?文生图/图生图大模型的架构设计看似复杂,实则遵循简单而有效的原则:合理排队、分工明确、防患未然。
334 14
文生图架构设计原来如此简单之分布式服务

热门文章

最新文章