做博客网站要怎么配置的服,网站快速查找,wordpress功能图,网站开发数据库课程设计前言#xff1a;此处描述的两个问题是在一年前发现并修复的。 本文仅用作历史证明#xff0c;也是有关解决Java中文件描述符泄漏的初学者指南。 在Ultra ESB中#xff0c;我们使用内存RAM磁盘文件缓存来进行快速且无垃圾的有效负载处理。 一段时间以前#xff0c;我们在共… 前言此处描述的两个问题是在一年前发现并修复的。 本文仅用作历史证明也是有关解决Java中文件描述符泄漏的初学者指南。 在Ultra ESB中我们使用内存RAM磁盘文件缓存来进行快速且无垃圾的有效负载处理。 一段时间以前我们在共享的SaaS AS2网关上遇到了一个问题该缓存随着时间的推移泄漏了文件描述符。 最终在击中系统ulimit时导致too many open files错误too many open files 。 有弹性的城堡军团流支持的MIME部分中的剩余部分 我们发现罪魁祸首是Bouncy Castle 这是著名的安全服务提供商自Ultra ESB Legacy时代起就一直是我们的挚爱。 通过一些简单的工具我们发现BC习惯了对MIME部分调用getContent()以确定它们的类型例如 instanceof检查。 没错这本身并不是犯罪。 但是我们的大多数MIME部分都是文件支持的 另一端带有文件缓存文件-这意味着每个getContent()都会为该文件打开一个新流。 因此现在有指向我们的文件缓存的杂散流以及文件描述符。 这些已经足够了我们将用尽分配给Ultra ESBJava进程的文件描述符配额。 让他们变得懒惰 我们不想弄乱BC代码库。 因此我们找到了一个简单的解决方案使用“惰性”流创建所有文件支持的MIME部分。 我们以前同事Rajind写了LazyFileInputStream -灵感LazyInputStream从jboss-vfs -打开只有当实际文件read尝试。 BC很高兴文件缓存也很高兴。 但是我们是最快乐的 Hibernate JPA晚饭后清理也就是关闭消耗的流 我们发现的另一个错误是某些数据库操作留下了未关闭的文件句柄。 显然只有当我们将流支持的Blob馈送到Hibernate时流才通常来自文件缓存项。 经过一番挖掘之后我们提出了一个理论即Hibernate不会关闭这些Blob条目的基础流。 这是有道理的因为java.sql.Blob接口没有公开Hibernate可以用来操作基础数据源的任何方法。但是这是一个问题因为丢弃的流以及关联的文件句柄不会得到发布直到下一个GC。 对于一个短期应用程序来说这本来可以但是像我们这样长期运行的应用程序很容易用完文件描述符。 例如突然而持续的峰值。 让他们自动关闭 我们不想失去流媒体的好处但是我们也无法控制流媒体。 您可能会说我们应该将流放在可自动关闭的结构中例如try-with-resources 。 不错的尝试; 但是可悲的是Hibernate在我们的执行范围之外特别是在Transactional流中读取它们。 一旦我们开始在代码范围内关闭流我们的数据库操作就开始惨败-尖叫“流已关闭”。 他们说 在罗马时就像罗马人一样 。 因此我们决定不打扰Hibernate而是决定自己处理流。 Rajind是的还是他再次入侵了SelfClosingInputStream包装器 。 这将跟踪从底层流读取的数据量并在读取最后一个字节后立即将其关闭。 我们确实考虑过使用现有选项例如来自Apache commons-io AutoCloseInputStream 但是发生了我们到处都需要一些自定义设置例如详细的跟踪日志记录。 底线 当涉及到Java中的资源管理时很容易过度关注内存和CPU处理而忽略其余部分。 但是虚拟资源例如临时端口和每个进程的文件描述符 可能同样重要甚至更多。 尤其是在长时间运行的流程例如我们的AS2 Gateway SaaS应用程序上它们实际上可以成为沉默的杀手。 您可以通过两种主要方式检测这种“泄漏” “单周期”资源分析 运行一个完整的处理周期比较前后的资源使用情况 长期监控 持续记录和分析资源指标以识别趋势和异常 在任何情况下修复泄漏都不是一件容易的事。 一旦您清楚地了解要处理的内容。 祝您好运寻找您的资源消耗da守护程序 翻译自: https://www.javacodegeeks.com/2019/10/is-your-jvm-leaking-file-descriptors-like-mine.html
