有次运维群里收到报警：一台 8 核 16G 的服务 CPU 突然飙到 100%，持续 3 分钟没下来。 上去 top -H 一看，GC 线程没跑，业务线程没打满。占了 700% CPU 的是 tomcat 的 http-nio-8080-exec——就一个线程。 这就邪门了。一个请求，一个线程，吃的 CPU 顶得上 7 个核。 顺着线程 dump 看下去，热方法不是业务逻辑，不是数据库查询，是 com.fasterxml.jackson.core.json.UTF8JsonGenerator——Jackson 的序列化方法。 翻了一下接口参数：前端传了 pageSize=100000。数据库一条 SELECT * FROM order_history WHERE ... 跑出来 10 万行，MyBatis 映射完开始在 controller 里序列化成 JSON 写回 Response。 10 万条订单记录，每条约 80 个字段，序列化完 200MB 的 JSON。Jackson 在单线程里逐条序列化，边序列化边往内存里攒——CPU 不炸才怪。 一、全量序列化为什么这么耗CPU 很多....

导语 PDF 导出是企业应用中常见的功能需求，如生成报表、合同、发票、证书等。SpringBoot 作为主流的 Java 后端框架，提供了多种实现 PDF 导出的方案。本文将深入探讨 SpringBoot 中实现 PDF 导出的各种方法，包括技术选型、实现细节、性能优化和最佳实践。 一、PDF 导出技术选型 1.1 主流 PDF 库比较 库名称许可证特点适用场景 iText 7AGPL/商业功能强大，支持复杂文档企业级应用，复杂报表 OpenPDFLGPLiText 5 的开源分支中小型应用，简单报表 Apache PDFBoxApache 2.0功能丰富，支持 PDF 操作PDF 解析和生成 Flying SaucerLGPL基于 XHTML/CSS 生成 PDF基于模板的文档 JasperReportsLGPL强大的报表引擎复杂报表，数据可视化 1.2 技术选型建议 选择因素： 功能需求：是否需要复杂布局、表单、图表等 许可证：是否需要商业使用 性能要求：处理大量数据的效率 学习曲线：开发和维护成本 社区支持：文档和资源的丰富程度 推荐方案： 小型应用：OpenP....