有人建议，为了提高我们系统的性能，应该全面使用延迟加载。这是将带有“mappedBy”属性的OneToOne映射更改为@OneToMany映射。这是为了解决和停止从数据库加载不需要的数据，这会导致应用程序的运行缓慢。
我们运行多层系统（基本上是2层）。我们有前端 - 使用JSF和后端，它包含业务和数据库访问层。前端和后端通信视图EJB - 但EJB中没有真正的逻辑。使用的其他技术 - Spring和Hibernate
现在，在对该主题进行一些阅读之后，似乎使用lazing loading并不是一个银弹，因为它需要正确应用。对于每个延迟加载，将发出Select语句以获取数据。还有一个问题是，如果前端访问要延迟加载的属性并且会话/连接在后端关闭，那么我们将获得null。
上述问题是否正确？
那么，实施延迟加载解决方案或性能改进的最佳方法/实践是什么？如果可能的话，希望不是重做数据模型。
我最初的工作是与DBA小组合作，以了解两个系统之间的情况 - 查询的外观，我们如何使用数据等。识别故障点，检查Hibernate对象/查询看看如何最好地改进它。还要查看前端以确定数据从后面传递到前面的内容和方式等等。
好方法/其他方法？
答案 0 :(得分：8)
您应该做的第一件事就是衡量您的应用程序并找出导致性能问题的确切原因。
使用JProfiler之类的工具找出问题所在。
一旦你知道发生了什么，你就可以决定如何修复它。
直接实施延迟加载方案而不知道导致性能问题的原因将浪费您的时间。
如果您发现数据库层是问题所在，那么您可以让DBA参与进来，看看您的架构/查询是否可以在做更激进的事情之前得到改进。
答案 1 :(得分：2)
确实如果你的数据提取减慢了你的加载时间，那么延迟加载是一个很好的解决方案。但是全面应用它似乎是一个不成熟的优化。您可能希望为每组数据实现它，然后测试它是否加速了应用程序。如果没有，那么它不适合延迟加载。
我实现延迟加载的方式导致数据层没有变化。在业务逻辑和演示控制器中都是如此。由于我不熟悉EJB，我将假设这适用于您的Java应用程序。无论如何，当我实现延迟加载时，我没有加载任何数据（atleat没有任何数据，我将懒得加载），直到需要它为止。然后我调用数据层并获取我的数据（或数据的子集）。
至于连接问题，您需要放置检查以测试数据连接以查看它是否已关闭。也就是说，您正在汇集数据连接。然后，如果连接已关闭，则重新打开它。但与实际的延迟加载实现一样，这应该在您的逻辑类中完成，而不是在前端，因此您不必多次复制此功能。
答案 2 :(得分：0)
延迟加载非常适合延迟昂贵的操作，但我同意您的结论，即它不是解决所有性能问题的灵丹妙药。
继续你的直觉，先做一些分析，看看应用程序中真正的性能问题在哪里。可能会发现延迟加载一些数据将是一个很好的解决方案，或者它可能是完全不同的东西。在你开始分析和分析应用程序内部的内容之前，真的没办法告诉你。
答案 3 :(得分：0)
这很大程度上取决于你想要做什么，这很难说。你去DBA的想法可以很有效率，最终。人们可能做的唯一事情是提供一些例子。就我而言：
在以下情况下，延迟加载对我们来说是一个巨大的性能提升。我们有一棵巨大的树，有15,000个不同级别的节点。最初我们尝试加载整个树然后渲染它。花了很长时间。我们更改了代码，仅在用户扩展节点时才懒惰地加载分支。节点扩展需要稍长的时间，但应用程序整体感觉更快。在这种情况下，更改映射
是有意义的现在，如果你需要处理整个树，因为你的业务逻辑需要它，延迟加载不会有太大的区别。在这种情况下，只更改映射实际上没有解决方案，甚至可能更昂贵。
您需要仔细考虑一下您的应用程序的作用，它在哪些方面感觉很慢，您想要完成什么。拉出探查器也不是银弹。
如果没有应用程序中的特定示例，则说延迟加载是否有用是没有意义的。