关于垃圾收集器的问题。 如果我已经创建了数据库连接并在数据库上执行了一些操作，之后我很长时间没有使用连接对象，垃圾收集器可以释放我的连接。我希望稍后使用此连接。
编辑：只是为了确认，如果我创建的连接位于 web 应用程序的上下文级别，那么情况如何？
如果您保留对 Connection 对象的
strong引用，那么垃圾收集器将永远不会接触您的对象，并且数据库连接将保留。请记住它不能被多个线程使用。
另一方面，如果保持打开的连接时间过长，某些底层资源（如 TCP/IP 套接字）可能会被中断。
如果您丢失了对连接的最后一个引用（通过覆盖它或设置为
nullconnection.close();
JVM 垃圾收集简而言之：如果您或其他任何人拥有对某个对象的引用，则不允许 JVM 对其进行垃圾收集。如果您没有对它的引用，那么 JVM 不会有对它进行垃圾收集，直到它想要为止。
只要您保留对连接的引用，该连接就不会被垃圾收集。因此，理论上您可以随心所欲地继续使用它。
如果不再引用该连接对象，那么它就是垃圾回收的成员，但绝不保证它会被 gc 垃圾回收。这完全取决于 gc。
如果以后想使用它，最好将其设为全局对象。这样你的应用程序就会保留一个引用，并且不会成为垃圾收集的成员。
取决于您的连接参考类型。如果你有强引用，那么它不会被垃圾收集，但如果你有弱引用，那么它将有资格被GC。
如果它由静态或实例级别保存，则不会被垃圾收集。
但是，您应该在需要时释放并重新获取数据库连接，而不是长时间保留数据库连接（考虑到每个数据库都有连接数量限制）。
您还应该考虑使用 ConnectionPool 来实现更好的连接管理。
您似乎正在处理 Glassfish 应用程序服务器中的 JDBC 连接泄漏问题。以下是监控和识别泄漏可采取的步骤摘要：
启用监控： 转至配置 -> 服务器配置 -> 监控。 选中监控服务旁边的启用复选框。 将 JDBC 连接池的监控级别设置为“高”。
查看监控数据： 导航到服务器链接中的“监视器”选项卡。 转到“资源”选项卡以查看 JDBC 连接池数据。 查找 WaitQueueLength 中的高值，表明有许多连接请求正在排队。
启用连接泄漏监控： 转到连接池的“高级”选项卡。 为泄漏超时设置一个非零值以启用泄漏监控。
这些步骤应该可以帮助您识别并解决连接泄漏问题。