采用懒加载技术来提升性能，是否值得？

Question

建议我们在整个系统中使用懒加载来提高性能。这意味着将OneToOne映射更改为带有“mappedBy”属性的@OneToMany映射。这样做是为了解决从数据库加载不必要数据导致应用程序缓慢的问题。

我们运行一个多层系统（基本上是2层）。我们有前端-使用JSF和包含业务和数据库访问层的后端。前端和后端通过EJB通信，但EJB中没有真正的逻辑。其他技术使用-Spring和Hibernate。

现在，在阅读了一些相关主题后，似乎懒加载的使用并非万无一失，因为它需要正确应用。对于每个懒加载，都会发出一个Select语句来获取数据。还存在这样的问题：如果前端访问要懒加载的属性，并且后端关闭了会话/连接，则会得到null。

以上是否正确？

那么，实施懒加载解决方案或性能改进的最佳方法/实践是什么？希望尽可能不重新设计数据模型。

我的初步想法是与DBA团队合作，了解两个系统之间的情况-查询的外观，如何使用数据等。确定问题点，检查Hibernate对象/查询以找出如何最好地改进它。还要查看前端，以确定如何从后端传递和显示数据等。

这是一个好方法/其他方法吗？

- boyd4715

Answer 1

你应该首先测量你的应用程序，找出导致性能问题的具体原因。使用像JProfiler这样的工具来查找问题所在。

一旦你知道了问题所在，就可以决定如何解决它。如果你不知道性能问题的根源就直接实现懒加载机制，那将是浪费时间的行为。

如果你发现DB层是问题所在，那么在做任何更彻底的改变之前，你可以让DBA参与其中，看看是否可以改进你的架构/查询。

- Glen

---

我通常会在错误的地方认为程序变慢了，所以我学会了进行性能分析而不是猜测。 - James Black

@James，是的，我也曾经尝试过猜测瓶颈在哪里，但被咬了太多次。在进行任何更改之前，通过某种方式测量代码会更容易、更快速和更准确。 - Glen

Answer 2

如果数据获取减缓了您的加载时间，那么懒加载确实是一个很好的解决方案。但是将其应用于所有数据似乎是一种过早的优化。您可能希望为每组数据实施它，然后测试是否加速了应用程序。如果没有加速，则不适合使用懒加载。

我实现懒加载的方式并没有改变数据层。所有操作都在业务逻辑和表示控制器中完成。由于我不熟悉EJB，我会假设这对于您的Java应用程序也适用。无论如何，当我实现懒加载时，我不加载任何数据（至少不是我要懒惰加载的数据），直到需要它。然后我调用数据层并获取我的数据（或数据子集）。

至于连接问题，您需要放置检查来测试数据连接是否关闭，即是否正在池化数据连接。然后，如果连接已关闭，请重新打开它。但是与实际的懒加载实现一样，这应该在逻辑类中完成，而不是在前端中完成，以避免多次重复此功能。

- alanquillin

Answer 3

延迟加载对于推迟昂贵的操作非常有用，但我同意你的结论，它并不是解决所有性能问题的万能药。

跟随你的直觉，首先进行一些分析，看看应用程序中真正的性能问题在哪里。可能会发现延迟加载某些数据是一个好的解决方案，或者可能完全不同。在开始分析应用程序内部发生了什么之前，真的没有办法知道。

- Eric Petroelje

Answer 4

这很大程度上取决于你想做什么，所以很难说。去找你的数据库管理员是个好主意，肯定会有帮助的。人们能做的唯一的事情可能就是提供一些例子。在我的情况下：

对于我们来说，延迟加载在以下场景中是一个巨大的性能提升。我们有一个包含15,000个不同级别节点的巨大树形结构。最初我们尝试加载整个树形结构然后渲染它。这需要很长时间。我们将代码更改为仅在用户展开节点时才延迟加载分支。节点展开时需要稍微更长的时间，但整个应用程序感觉更快了。在这种情况下，更改映射是有意义的。

现在，如果您需要处理整个树形结构，因为它是业务逻辑所必需的，那么延迟加载并没有太大的区别。在这种情况下，仅更改映射并不是真正的解决方案，甚至可能更加昂贵。

您需要思考一下您的应用程序在哪些地方感觉缓慢，您想要实现什么目标。使用分析器也不是万能的。

如果没有来自您的应用程序的具体示例，那么说延迟加载是否有用就没有意义。

- Mario Ortegón