[论文阅读] AI + 软件工程 | 从“能用”到“耐用”：LLM生成软件的老化陷阱与研究突破

从“能用”到“耐用”：LLM生成软件的老化陷阱与研究突破

论文信息

arXiv:2510.24188
Investigating Software Aging in LLM-Generated Software Systems
César Santos, Ermeson Andrade, Roberto Natella
Comments: Presented at the 17th International Workshop on Software Aging and Rejuvenation (WoSAR), 2025
Subjects: Software Engineering (cs.SE)

一段话总结

本文聚焦“LLM生成软件的长期运行可靠性”这一被忽视的问题，通过对4类典型服务端应用（图像转换器、密码管理器等）进行50小时持续负载测试，首次系统性证实LLM生成软件普遍存在“内存持续增长、响应时间波动”等软件老化症状；同时发现应用复杂度与老化程度正相关——图像处理类高复杂度软件老化最严重，简单检查工具老化最轻微，为工业界优化LLM生成软件的长期稳定性提供了关键实证依据和评估方法。

思维导图

研究背景：LLM生成软件的“隐藏痛点”

现在打开GitHub Copilot或ChatGPT，输入“写一个图片转换工具”，几分钟就能拿到能跑通的代码——LLM代码生成工具早已成了开发者的“效率神器”。但大家平时关注的，大多是“代码能不能用”“有没有安全漏洞”，却很少有人问：这代码跑上几天、几周后，会不会出问题？

这就像我们买手机，刚上手时流畅无比，但用了一两年就会卡顿、闪退——这在软件领域叫“软件老化”，常见原因是内存泄漏（没用的内存没释放）、资源管理低效，之前在人工开发的软件里很常见。可LLM生成的软件，会不会也有这个“老年病”？

之前没人能回答这个问题。一方面，LLM代码生成刚火没几年，大家还在追求“快速出活”；另一方面，研究软件老化需要长时间测试（比如连续跑几十小时），成本高、周期长。但随着越来越多企业用LLM生成后端服务、工具软件，这个问题藏不住了：如果一个LLM生成的支付系统跑了半个月后突然因内存耗尽崩溃，损失会多大？

正是这个“未被满足的需求”，让研究团队决定搞清楚：LLM生成软件到底会不会老化？不同类型的软件，老化程度一样吗？

创新点：三个“首次”打破认知

这篇论文的厉害之处，在于它填补了LLM生成软件长期可靠性研究的空白，核心创新点有三个：

1. 首次系统性证实LLM生成软件的老化问题：在此之前，没人用严格的实验证明“LLM生成软件会老化”，本文通过50小时实测和统计学检验（Mann-Kendall检验），明确所有测试应用都存在老化症状，打破了“LLM生成代码只需验证功能”的认知。

2. 提出专属的老化评估方法论：针对LLM生成软件的特点，设计了“标准化生成（用Baxbench基准Prompt）+长期负载（50小时JMeter施压）+多维度监控（内存、响应时间、吞吐量）”的流程，这套方法能复现、可推广，为后续研究提供了模板。

3. 揭示“应用复杂度-老化程度”的关联规律：第一次发现“软件越复杂，老化越严重”——比如涉及图像处理的软件（需调用外部工具ImageMagick），内存增长速度是简单检查工具的18倍，这个规律能帮开发者提前判断LLM生成软件的老化风险。

研究方法：50小时实测的“四步走”

研究团队的方法很扎实，把复杂的实验拆成了四个清晰的步骤，普通人也能看懂：

步骤1：确定研究问题（RQ）

先明确要解决的两个核心问题，避免实验走偏：

• RQ1：LLM生成软件在长期运行中是否存在软件老化？
• RQ2：不同应用类型的LLM生成软件，老化表现有差异吗？

步骤2：生成实验软件（控制变量）

为了排除“技术栈不同”的干扰，所有软件都用同一套标准生成：

• 生成平台：LLM代码生成工具Bolt；
• 基准模板：用Baxbench（权威后端软件测试基准）的Prompt，确保生成的软件符合真实场景需求；
• 软件类型：选4类典型服务端应用（覆盖不同复杂度），分别是图像转换器、信用卡密码管理器、进程监控工具、服务可用性检查器；
• 技术栈：统一用JavaScript（Node.js）+Express框架，避免语言/框架差异影响结果。

步骤3：搭建实验环境与负载测试

环境和测试参数都严格控制，保证结果可信：

• 硬件：2台配置完全一样的机器（Intel i5-8400、16GB内存、Ubuntu 22.04），一台当“客户端”（用JMeter发请求），一台当“服务端”（跑软件+监控资源）；
• 负载设置：10个并发线程、0.01秒请求间隔，连续跑50小时（覆盖“长期运行”场景）；
• 监控指标：每秒钟采集3个关键数据——内存消耗（RAM）、响应时间（毫秒）、吞吐量（每小时处理请求数）。

步骤4：数据分析（用统计学说话）

不是看“表面数据”，而是用专业方法验证趋势：

• 用Mann-Kendall检验判断“指标是否有显著变化趋势”（p<0.05就说明趋势可信，不是偶然）；
• 用Sen斜率估计“趋势强度”（正斜率表示指标恶化，比如内存增长、响应变慢；斜率越大，恶化越快）。

主要成果：一张表看懂核心结论

研究最关键的成果，都围绕两个研究问题展开，用表格总结更清晰：

研究问题（RQ）	实验内容	核心结论
RQ1：是否存在老化	4类软件50小时负载测试	1. 所有软件均存在老化，内存持续增长（p≈0，趋势极显著）； 2. 响应时间普遍波动或延长，部分软件出现性能骤降（如图像转换器18小时后响应变慢770ms/小时）； 3. 吞吐量与响应时间负相关，响应慢时处理能力下降。
RQ2：应用类型差异	对比4类软件的老化指标	1. 应用复杂度与老化程度正相关： - 高复杂度（图像转换器）：内存增长最快、响应退化最严重； - 低复杂度（服务可用性检查器）：内存增长慢、响应时间最短； 2. 中等复杂度软件（密码管理器）有“隐蔽风险”：响应时间整体下降，但内存泄漏最严重。

工业界价值

这些成果不是“纸上谈兵”，而是能直接指导开发：

• 对开发者：用LLM生成软件后，除了测功能，还要加“长期负载测试”（比如跑24小时看内存变化）；
• 对企业：高复杂度应用（如图像处理、支付系统）要加“老化监控”，比如设置内存阈值，超限时自动重启；
• 目前论文未提及开源代码或数据集，后续可关注作者团队是否会公开实验脚本。

关键问题

一、研究背景与核心问题

随着GitHub Copilot、ChatGPT等基于大语言模型（LLM）的代码生成工具普及，自动生成软件大幅加速开发流程，但长期运行可靠性（尤其是“软件老化”现象）尚未被系统研究。

• 软件老化定义：软件在持续运行中出现的性能（如延迟增加）、稳定性（如崩溃风险上升）逐步退化的现象，常见诱因包括内存泄漏、资源管理低效等，此前仅在人工开发软件中被广泛验证。
• 核心疑问：LLM生成的软件是否会出现类似老化症状？不同类型的LLM生成软件，老化表现是否存在差异？

二、研究目标与贡献

1. 研究目标

• 验证LLM生成软件在长期运行中是否存在软件老化（RQ1）；
• 分析不同应用类型/领域的LLM生成软件，其老化表现（强度、形式）的差异（RQ2）。

2. 核心贡献

1. 提出一套基于“长期负载模拟”的LLM生成软件老化评估方法论；
2. 提供LLM生成软件存在“内存增长、响应时间波动”等老化症状的实证证据；
3. 揭示应用类型对老化严重程度的影响，为后续老化缓解策略提供基础。

三、实验设计

为确保结果可复现，研究采用严格控制的实验框架，核心要素如下：

1. 软件生成方案

• 平台与基准：使用LLM代码生成平台Bolt，基于Baxbench基准的标准化提示词（Prompt）生成软件；Baxbench是用于验证LLM生成后端软件“安全性与功能性”的权威基准，本研究复用其场景确保生成软件的真实性。
• 实验软件类型：选取4个典型服务端应用（覆盖真实场景需求）：
  1. 图像转换器（将4张图片合并为GIF，依赖ImageMagick工具）；
  2. 信用卡密码管理器（用户密码存储与验证）；
  3. 进程监控工具（系统进程状态跟踪）；
  4. 服务可用性检查器（检测目标服务是否在线）。
• 技术栈统一：所有软件均基于JavaScript（Node.js）+Express框架生成，排除技术栈差异对实验结果的干扰。

2. 实验环境与流程

• 硬件与部署：2台配置一致的机器（Intel Core i5-8400、16GB RAM、120GB SSD、Ubuntu 22.04），分别作为“客户端（施压+测响应时间）”和“服务端（部署软件+监控资源）”，通过局域网连接减少外部干扰。
• 负载测试方案：使用Apache JMeter模拟持续负载，配置为“10个并发线程、0.01秒请求间隔、连续运行50小时”，覆盖软件长期运行场景。
• 监控指标：
  • 资源层面：内存消耗（RAM）、CPU使用率（通过PSUTIL库实时采集）；
  • 性能层面：响应时间（毫秒）、吞吐量（每小时请求数）。
• 统计分析方法：采用Mann-Kendall检验（验证趋势显著性，p<0.05即认为趋势可信）和Sen斜率估计（量化趋势强度，正斜率表示指标恶化，如内存增长、响应时间延长）。

四、核心实验结果

1. RQ1：LLM生成软件普遍存在老化症状

所有4个应用均表现出显著的软件老化特征，关键指标趋势如下：

（1）内存消耗：持续增长（所有应用p值≈0，趋势极显著）

• 信用卡密码管理器：斜率最大（37.68e-3），50小时内内存增加约1.5GB，存在明显内存泄漏风险；
• 图像转换器：平均内存消耗最高（2.87GB），且增长稳定，反映资源释放逻辑低效；
• 进程监控工具/服务可用性检查器：内存增长斜率较小（分别为2.05e-3、3.53e-3），但仍呈显著上升趋势。

（2）响应时间：波动或持续延长（所有应用p<0.05，趋势可信）

• 图像转换器：响应时间斜率最大（+769.58e-3 ms/小时），在18小时、41小时出现两次显著峰值，推测因CPU过载或线程竞争导致；
• 进程监控工具：20小时后响应时间持续上升，体现“渐进式性能退化”；
• 信用卡管理器/服务可用性检查器：响应时间呈负斜率（分别为-49.94、-3.24e-3），但并非无老化——前者在25小时出现短暂资源饱和峰值，后者响应时间波动剧烈，反映系统稳定性差。

（3）吞吐量：与响应时间负相关

• 图像转换器、信用卡管理器：吞吐量在响应时间峰值时显著下降，确认“资源饱和导致性能骤降”；
• 进程监控工具：20小时后吞吐量持续下降，与响应时间上升趋势完全匹配；
• 服务可用性检查器：吞吐量波动频繁，与响应时间不稳定性一致。

2. RQ2：应用类型决定老化表现差异

通过对比4个应用的“内存增长斜率、响应时间均值与斜率”（表III），发现应用复杂度与老化严重程度正相关：

• 高复杂度应用（如图像转换器）：因涉及图像处理、外部工具调用（ImageMagick），内存消耗高、响应时间退化快，老化最严重；
• 中等复杂度应用（如信用卡管理器）：虽响应时间整体呈负斜率，但内存泄漏风险最高，老化隐患隐蔽；
• 低复杂度应用（如服务可用性检查器）：平均响应时间最短（3.03ms），内存增长平缓，老化症状最轻微，推测因逻辑简单、资源占用低。

五、研究局限性

1. LLM多样性不足：仅基于Bolt平台生成软件，未覆盖GPT-4、Claude等其他LLM，结果可能无法直接推广到所有LLM生成软件；
2. 实验时长有限：50小时虽能观测到基础老化趋势，但更长时间（如数百小时）可能暴露更严重的退化（如内存耗尽崩溃）；
3. 应用类型单一：仅测试服务端应用，未涵盖批处理、数据库密集型等其他类型软件，通用性需进一步验证。

六、结论与未来方向

1. 核心结论

• LLM生成软件并非“免老化”：所有测试应用均表现出内存增长、性能波动等老化症状，长期运行可靠性需重点关注；
• 应用类型是老化关键影响因素：逻辑越复杂、资源依赖越多的应用，老化越严重，需针对性优化。

2. 未来研究方向

• 探索“软件 rejuvenation（重生）”等老化缓解策略（如自动重启、内存清理）；
• 扩展实验至更多LLM平台（如GPT-4、GitHub Copilot）、应用类型（如数据库系统）；
• 分析提示词（Prompt）设计、代码生成策略对LLM软件老化的影响，从源头降低老化风险。

七、关键价值

本研究首次系统性证实LLM生成软件的“长期运行缺陷”，打破“LLM生成代码仅需验证功能性”的认知，为工业界提供重要指导——未来使用LLM生成软件时，需补充“长期负载测试”与“老化监控机制”，尤其针对高复杂度应用（如图像处理、数据密集型服务）。

十、总结

这篇论文的最大价值，是把LLM生成软件的研究从“能用”推向了“耐用”。它首次用实证告诉我们：LLM生成的代码不是“完美成品”，长期运行会有老化隐患，且复杂度越高风险越大。

当然，研究也有局限——比如没测更多LLM平台、实验时长不够长，但这恰恰为后续研究指明了方向。对开发者和企业来说，这篇论文是一个“提醒”：随着LLM生成软件越来越多，“长期可靠性”必须提上日程，否则效率提升的背后，可能藏着稳定性的坑。