绝对不是！

Question

我在Tomcat上运行Web应用程序。我有一个处理所有数据库查询的类。该类包含Connection对象和返回查询结果的方法。

这是连接对象：

private static Connection conn = null;

它只有一个实例（单例）。

此外，我还有执行查询的方法，例如在db：

中搜索用户

public static ResultSet searchUser(String user, String pass) throws SQLException

此方法使用静态Connection对象。我的问题是，我在静态Connection对象线程中的使用是否安全？或者当很多用户调用searchUser方法时会导致问题吗？

Answer 1

是我在静态连接对象线程安全中使用的吗？

绝对不是！

这样，连接将在所有用户发送的所有请求之间共享，因此所有查询都会相互干扰。但是线程安全不是你唯一的问题，资源泄漏也是你的另一个问题。在整个应用程序的生命周期中，您将保持单个连接处于打开状态。平均数据库将在打开时间过长时回收连接，通常在30分钟到8小时之间，具体取决于DB的配置。因此，如果您的Web应用程序运行时间超过此时间，则连接将丢失，您将无法再执行查询。

当这些资源作为多次重复使用的类实例的非static实例变量保存时，此问题也适用。

你应该总是获取并关闭最短范围中的连接，语句和结果集，最好是在你所在的try-with-resources block内。根据以下JDBC习惯用法执行查询：

public User find(String username, String password) throws SQLException {
    User user = null;

    try (
        Connection connection = dataSource.getConnection();
        PreparedStatement statement = connection.prepareStatement("SELECT id, username, email FROM user WHERE username=? AND password=md5(?)");
    ) {
        statement.setString(1, username);
        statement.setString(2, password);

        try (ResultSet resultSet = statement.executeQuery()) {
            if (resultSet.next()) {
                user = new User();
                user.setId(resultSet.getLong("id"));
                user.setUsername(resultSet.getString("username"));
                user.setEmail(resultSet.getString("email"));
            }
        }
    }       

    return user;
}

请注意，不应在此处返回ResultSet。您应该立即读取它并将其映射到非JDBC类，然后将其返回，以便可以安全地关闭ResultSet。

如果您尚未使用Java 7，请使用try-finally块，其中您可以按照相反的顺序手动关闭可关闭的资源。您可以在此处找到示例：How often should Connection, Statement and ResultSet be closed in JDBC?

如果您担心连接性能，那么您应该使用连接池。它内置于许多Java EE应用程序服务器中，甚至像Tomcat这样的准系统servlet容器也支持它。只需在服务器本身中创建一个JNDI数据源，然后让您的webapp将其抓取为DataSource。它透明地已经是一个连接池。您可以在下面列表的第一个链接中找到一个示例。

另见：

Answer 2

如果您只运行Select次查询（searchUser听起来只是选择数据），除了线程争用之外，不存在任何问题。

据我所知，Connection一次只能处理一个查询，因此通过使用单个实例，您将基本上序列化数据库访问。但这并不一定意味着，在多线程环境中访问这样的数据库总是安全。如果并发访问是交错的，则可能仍然存在问题。

在多线程系统中使用静态java.sql.Connection实例是否安全？

2 个答案:

绝对不是！

另见：