最近公司里负责运维的同学急得团团转，监测OutSystems应用的容器内存曲线，每天都以固定的速度往上涨，看起来就像一个没拧紧的水龙头，直到某天突然直接把容器撑爆，只能强制重启才能回到正常状态，但没过几天又会重演这个崩溃的循环。排查了一圈普通的代码bug，比如局部变量没释放、循环引用，都没找到原因，最后才发现是三个隐藏的“内存小偷”在悄悄搞事情——会话状态残留、静态实体缓存过载、事件订阅泄漏堆积。
一、监控面板里的诡异曲线
1.1 从日常日志里发现的异常
运维同学一开始以为是业务流量波动大导致的，毕竟很多应用都会有流量高峰，内存跟着涨很正常，但连续观察了一周发现，哪怕是凌晨流量最低的时候，内存还是在匀速上涨，只是速度慢一点，一到业务高峰就涨得更快。而且每次重启后，内存会回到初始值，然后开始新一轮的缓慢上涨，这个规律一出现，就知道是内存泄漏，不是临时波动。
1.2 为什么不是常见的内存泄漏？
很多开发者遇到内存泄漏，第一反应是找全局变量没清理、大对象没释放这些，但这次的情况不一样：代码里根本没有全局的大对象，也没有循环引用的问题，问题出在OutSystems平台特有的机制上，比如会话管理、静态实体缓存、全局事件订阅，这些地方的处理不当，就会慢慢把内存吃掉。
二、找出三个隐藏的“内存小偷”
2.1 会话状态的“任性堆积”
OutSystems的会话是用来存用户登录状态、临时信息的，比如用户选了购物车的商品、填写了一半的订单信息，这些数据本来应该在用户登出或者关闭浏览器后清理，但很多新手开发者会直接把大量数据塞进Session，而且不设置过期时间，也不手动清理。比如用户的所有权限、最近一个月的浏览记录、偏好设置，都直接存在Session里，每个用户的Session都占了几MB，用户多了之后，几百个Session就把内存堆满了。
代码示例（OutSystems 11 后端 C#）
// 技术栈：OutSystems 11 原生平台（后端逻辑）
// 错误示例：直接把大对象存入Session，无清理逻辑
public void OnUserLogin()
{
// 把用户所有权限、近30天浏览记录、偏好全塞进Session，没有限制
Session["FullUserInfo"] = GetAllUserRelatedData(CurrentUser.Id);
Session["UserCartItems"] = GetAllCartItems(CurrentUser.Id);
Session["RecentBrowse"] = GetRecentBrowseRecords(CurrentUser.Id, 30);
// 未设置Session过期，也未在登出时删除这些数据
}
// 正确示例：Session只存必要的标识，数据按需获取
public void OnUserLogin()
{
// Session只存用户ID，大小只有几十字节
Session["CurrentUserId"] = CurrentUser.Id;
Session["IsLoggedIn"] = true;
// 需要用数据时，再从数据库或缓存里取，用完就释放
}
2.2 静态实体缓存的“贪吃鬼”
OutSystems里有静态实体，开发者喜欢用静态变量存经常要查的数据，比如商品列表、分类列表，这样不用每次都查数据库，提高性能。但很多时候，静态缓存里的数据只会加不会减，比如每次更新商品就往列表里加新数据，旧的不会删掉，或者测试环境里的大量测试数据，没清理干净，上线后还一直在缓存里，时间长了就堆成山。比如一个电商平台，静态缓存里存了100万条测试商品数据，上线后没清理，随着正式商品增加，缓存里的内容越来越多，直接把服务器内存吃完了。
代码示例（OutSystems 11 静态实体缓存）
// 技术栈：OutSystems 11 静态缓存（C#）
// 错误示例：静态列表无上限，一直加数据
public static List<Product> StaticProductCache = new List<Product>();
// 每次加载商品，就把所有数据加进缓存
public void LoadAllProducts()
{
// 缓存为空时，查数据库全量数据
if (StaticProductCache.Count == 0)
{
StaticProductCache = Database.GetAll<Product>().ToList();
}
// 有新商品时，直接添加，不清理旧数据
else
{
var newProducts = Database.GetNewProducts(StaticProductCache.Max(p => p.Id));
StaticProductCache.AddRange(newProducts); // 这里只会越来越多
}
}
// 正确示例：静态缓存设最大容量，超过就淘汰旧数据
public static List<Product> StaticProductCache = new List<Product>();
private const int MaxCacheSize = 1000; // 最多存1000个商品
public void LoadAllProducts()
{
if (StaticProductCache.Count == 0)
{
StaticProductCache = Database.GetAll<Product>().ToList();
}
else
{
var newProducts = Database.GetNewProducts(StaticProductCache.Max(p => p.Id));
StaticProductCache.AddRange(newProducts);
// 超过最大容量时，移除最旧的100个商品
if (StaticProductCache.Count > MaxCacheSize)
{
StaticProductCache.RemoveRange(0, StaticProductCache.Count - MaxCacheSize);
}
}
}
2.3 事件订阅的“隐形钩子”
不管是前端还是后端，都会用事件订阅来实现组件间的通信，比如商品更新后通知购物车、用户状态变了通知个人中心。但很多时候，组件或服务销毁时，忘记取消订阅，每次重新加载组件就多一个订阅，这些订阅就像一个个隐形的钩子，挂在内存里，不会被释放，时间长了，订阅的数量越来越多，每个订阅又带着对应的处理函数，内存就慢慢被吃完了。比如后端的订单服务，每次启动就订阅商品更新事件，每次重启就多一个订阅，几十次之后就有几百个钩子，内存自然暴涨。
代码示例（OutSystems 11 后端 事件订阅）
// 技术栈：OutSystems 11 后端（C# 事件订阅）
// 错误示例：后端服务的事件订阅未取消，导致泄漏
public class OrderService
{
public OrderService()
{
// 订阅商品更新事件
EventAggregator.Subscribe<ProductUpdatedEvent>(HandleProductUpdate);
}
private void HandleProductUpdate(ProductUpdatedEvent evt)
{
// 处理商品更新通知相关订单
UpdateRelatedOrders(evt.ProductId);
}
// 服务停止时，忘记取消订阅，导致订阅泄漏
// 正确做法：服务停止时添加以下代码
// EventAggregator.Unsubscribe<ProductUpdatedEvent>(HandleProductUpdate);
}
// 正确示例：服务销毁时取消订阅
public class OrderService : IDisposable
{
public OrderService()
{
EventAggregator.Subscribe<ProductUpdatedEvent>(HandleProductUpdate);
}
private void HandleProductUpdate(ProductUpdatedEvent evt)
{
UpdateRelatedOrders(evt.ProductId);
}
// 实现Dispose接口，服务销毁时自动取消订阅
public void Dispose()
{
EventAggregator.Unsubscribe<ProductUpdatedEvent>(HandleProductUpdate);
}
}
三、怎么排查这些内存小偷？
3.1 用OutSystems自带的工具看底细
OutSystems的Service Center里有内置的监控功能，比如“应用性能”模块，可以看每个应用的内存占用、会话数量、静态缓存大小。比如查看会话数量的曲线，是不是和内存曲线一样匀速涨；查看静态缓存的大小，是不是一直在增加；查看事件订阅的数量，有没有异常多的情况。
3.2 代码里找漏点
用刚才的示例里的写法，检查会话里存的内容是不是太多，静态缓存有没有上限，事件订阅有没有在销毁时取消，尤其是新开发的功能，很容易犯忘记清理的错误，最好加代码review的时候重点看这三个地方。
四、这些问题的应用场景
这类问题在中大型企业的OutSystems应用里特别常见，比如电商平台的会员系统、零售行业的订单管理系统，这些系统运行时间长，用户量多，业务流程复杂，很容易出现会话残留、缓存堆积、订阅泄漏，每次重启都要影响业务，尤其是大促期间，重启会导致订单支付失败，损失很大。
五、优化方案的优缺点
5.1 会话优化的优缺点
- 方案：设置Session过期时间，不要存大对象，只存必要的标识
- 优点：简单易实现，自动清理旧会话，内存释放快
- 缺点：如果Session里的过期时间设置太短，用户正在操作时被清理，会影响体验；设置太长，又会残留数据
5.2 静态缓存优化的优缺点
- 方案：设置静态缓存的最大容量，用淘汰机制清理旧数据，或者用弱引用缓存
- 优点：平衡性能和内存，不会堆太多没用的数据
- 缺点：弱引用缓存可能会在需要数据时被回收，导致查询变慢，需要权衡
5.3 事件订阅优化的优缺点
- 方案：用IDisposable接口管理服务生命周期，组件销毁时自动取消订阅
- 优点：防止订阅泄漏，内存稳定
- 缺点：需要正确实现接口，不然可能导致事件不触发，影响业务流程
六、开发和运维的注意事项
- 会话管理：永远不要把大对象（比如整个表的数据、用户详细的操作记录）存入Session，只存用户ID、登录状态这类小数据，需要用数据时再从数据库或缓存里取。
- 静态缓存：静态变量只用来存不经常变的小数据，比如配置信息，不要存业务数据的全量集合，就算要存，也必须设置最大容量，加上淘汰机制。
- 事件订阅：每次订阅事件后，必须在对应的组件或服务销毁时取消，不管是前端还是后端，都要检查订阅和取消的配对，用工具监控订阅数量，及时发现异常。
- 运维：平时要监控内存曲线、会话数量、缓存大小，设置告警，一旦出现匀速上涨的情况，就及时排查，不要等到容器重启才处理。
七、总结
OutSystems应用长时间运行后内存持续增长，大部分情况不是核心功能的bug，而是三个容易被忽略的机制问题：会话残留、静态缓存过载、事件订阅泄漏，只要按上面的方法排查，从代码层面清理残留，设置合理的缓存大小，及时取消事件订阅，就能让内存保持稳定，避免容器频繁重启，保障业务的稳定运行。
评论
围绕“OutSystems长时间运行后内存持续增长，直到容器重启才发现是会话状态残留、静态实体缓存与事件订阅泄漏在悄悄堆积”参与讨论