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

简介:

对于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程序!

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

目录
相关文章
|
2月前
|
存储 前端开发 Java
Kotlin教程笔记 - MVVM架构怎样避免内存泄漏
Kotlin教程笔记 - MVVM架构怎样避免内存泄漏
33 2
|
3月前
|
Cloud Native Java API
聊聊从单体到微服务架构服务演化过程
本文介绍了从单体应用到微服务再到云原生架构的演进过程。单体应用虽易于搭建和部署,但难以局部更新;面向服务架构(SOA)通过模块化和服务总线提升了组件复用性和分布式部署能力;微服务则进一步实现了服务的独立开发与部署,提高了灵活性;云原生架构则利用容器化、微服务和自动化工具,实现了应用在动态环境中的弹性扩展与高效管理。这一演进体现了软件架构向着更灵活、更高效的方向发展。
|
3月前
|
存储 前端开发 Java
Android MVVM架构模式下如何避免内存泄漏
Android采用MVVM架构开发项目,如何避免内存泄漏风险?怎样避免内存泄漏?
123 1
|
4月前
|
存储 Linux KVM
Proxmox VE (PVE) 主要架构和重要服务介绍
Proxmox VE (PVE) 是一款开源的虚拟化平台,它基于 KVM (Kernel-based Virtual Machine) 和 LXC (Linux Containers) 技术,支持虚拟机和容器的运行。PVE 还提供高可用集群管理、软件定义存储、备份和恢复以及网络管理等企业级功能。
1505 7
|
25天前
|
消息中间件 存储 安全
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
58 11
|
2月前
|
Kubernetes Cloud Native Docker
云原生之旅:从传统架构到容器化服务的演变
随着技术的快速发展,云计算已经从简单的虚拟化服务演进到了更加灵活和高效的云原生时代。本文将带你了解云原生的概念、优势以及如何通过容器化技术实现应用的快速部署和扩展。我们将以一个简单的Python Web应用为例,展示如何利用Docker容器进行打包和部署,进而探索Kubernetes如何管理这些容器,确保服务的高可用性和弹性伸缩。
|
3月前
|
消息中间件 Kafka 数据库
微服务架构中,如何确保服务之间的数据一致性?
微服务架构中,如何确保服务之间的数据一致性?
|
3月前
|
存储 前端开发 Java
Kotlin教程笔记 - MVVM架构怎样避免内存泄漏
Kotlin教程笔记 - MVVM架构怎样避免内存泄漏
69 1
|
3月前
|
存储 分布式计算 druid
大数据-155 Apache Druid 架构与原理详解 数据存储 索引服务 压缩机制
大数据-155 Apache Druid 架构与原理详解 数据存储 索引服务 压缩机制
80 3
|
4月前
|
消息中间件 Kafka 数据库
微服务架构中,如何确保服务之间的数据一致性
微服务架构中,如何确保服务之间的数据一致性