httpclient连接泄漏实战-_-

原创 已于 2023-06-05 10:24:53 修改 · 1.6k 阅读 · 4 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#apache #java #httpclient #连接池 #tomcat

于 2023-05-27 21:01:16 首次发布

用法

常用构造方法

private HttpClient newHttpClient() {
    Registry<ConnectionSocketFactory> socketFactoryRegistry = RegistryBuilder
            .<ConnectionSocketFactory>create()
            .register("http", PlainConnectionSocketFactory.INSTANCE)
            .register("https", Objects.nonNull(this.connectionSocketFactory) ? this.connectionSocketFactory : SSLConnectionSocketFactory.getSocketFactory()).build();

    //设置连接池大小
    PoolingHttpClientConnectionManager connManager = new PoolingHttpClientConnectionManager(socketFactoryRegistry);
    // 全局最大连接数
    connManager.setMaxTotal(this.maxConnPerTotal);
  	// 每个路由的最大连接数
    connManager.setDefaultMaxPerRoute(this.maxConnPerRoute);

    return HttpClients.custom().setKeepAliveStrategy(new DefaultDurationConnectionKeepAliveStrategy())
            .setConnectionManager(connManager).build();
}

请求配置

protected RequestConfig buildRequestConfig() {
    return RequestConfig.custom()
            .setConnectTimeout(this.connectTimeout)
            .setSocketTimeout(this.socketTimeout)
            .setCookieSpec(CookieSpecs.STANDARD)
            .build();
}

响应处理

注意：EntityUtils.toString处理会关闭并释连接

private final ResponseHandler<String> responseHandler = response -> {
    int status = response.getStatusLine().getStatusCode();
    HttpEntity entity;
    if (status >= HttpStatus.SC_OK && status < HttpStatus.SC_MULTIPLE_CHOICES) {
        entity = response.getEntity();
        return entity != null ? EntityUtils.toString(entity) : null;
    } else {
        String errorMsg = null;
        if ((entity = response.getEntity()) != null) {
            errorMsg = EntityUtils.toString(entity);
        }
        throw new HttpResponseException(status, errorMsg);
    }
};

模型

PoolEntry

包含连接池中的一个连接与它的路由

  1. route：路由，例如：org.apache.http.conn.routing.HttpRoute
  2. conn：连接池中的一个连接
  3. state：状态信息，可以在释放连接时指定状态信息，在租用时也可以指定状态信息，可以借助此字段来定制化连接复用策略
  4. created：创建时间戳
  5. updated：更新时间戳
  6. validityDeadline：PoolEntry的有效期截止日期时间戳
  7. expiry：有消息，同validityDeadline，区别在于该字段允许修改，validityDeadline不允许修改

RouteSpecificPool

每个路由的连接池，是连接池CPool的子集
属性

  1. available: 是一个链表，可复用的PoolEntry（包含连接池中的一个连接与它的路由）,在leased租借释放时从leased转移而来
  2. leased：已租借集合，当RouteSpecificPool已分配数量小于maxPerRoute并且小于maxTotal，创建新连接，或者在available存在可复用连接时转移而来
  3. pending：当RouteSpecificPool已分配数量大于等于maxPerRoute并且大于等于maxTotal，将请求PoolEntry的future缓存至pending并等待有空闲资源时被唤醒。如果有超时时间，超时未拿到资源将抛出超时异常：throw new TimeoutException(“Timeout waiting for connection”)。注意：如果未设置超时时间，将永久等待

方法

  1. getFree：返回空闲资源，不为空则将LeaseRequest设置为已完成（即isDone=true）。并且将CPool的该资源由available转移至leased

CPool

连接池
属性

  1. maxTotal：全局最大可用资源数量
  2. available: RouteSpecificPool.available是其子集
  3. leased：RouteSpecificPool.leased是其子集
  4. pending：RouteSpecificPool.pending是其子集
  5. leasingRequests：租赁中的请求链表，当LeaseRequest请求未完成，并且processPendingRequest未完成时，将LeaseRequest添加至该链表
  6. completedRequests：已完成请求队列，当LeaseRequest请求完成时，将LeaseRequest添加至该队列
  7. totalUsed=maxTotal-pending-leased

方法

  1. fireCallbacks：处理completedRequests队列
  2. release:释放已租借资源

HttpResponseProxy

响应体代理对象，该对象会对普通响应体进行增强，增强后的响应体Entity为代理：ResponseEntityProxy，主要增强功能如下

  1. 实现了EofSensorWatcher接口，可以监听InputStream数据流，在关闭/中断/检测到EOF时同时释放连接
  2. 继承了HttpEntityWrapper类，重写了getContent方法，将原InputStream封装为EofSensorInputStream
    public HttpResponseProxy(final HttpResponse original, final ConnectionHolder connHolder) {
        this.original = original;
        this.connHolder = connHolder;
      	// 增强响应体
        ResponseEntityProxy.enchance(original, connHolder);
    }
    public static void enchance(final HttpResponse response, final ConnectionHolder connHolder) {
        final HttpEntity entity = response.getEntity();
        if (entity != null && entity.isStreaming() && connHolder != null) {
            response.setEntity(new ResponseEntityProxy(entity, connHolder));
        }
    }

流程

连接池-获取连接

为什么是totalAvailable > freeCapacity - 1才释放available连接？
因为逻辑走到此处，紧接着会创建一个新的连接，也就是说freeCapacity的数量会减少1。如果不减1的话则会出现连接数溢出1的场景（每个路由会溢出1，路由越多溢出越多）
连接池.drawio.png

请求服务端

  1. 如果开启了staleConnectionCheckEnabled校验，则检查连接是否已stale，是则关闭
  2. 如果HttpExecutionAware不为空则回调：org.apache.http.client.methods.HttpExecutionAware#setCancellable
  3. 如果HttpExecutionAware不为空，检查是否已aborted连接，是则抛出异常：throw new RequestAbortedException(“Request aborted”);
  4. 如果连接未打开，建立目标路由：org.apache.http.impl.execchain.MainClientExec#establishRoute
  5. 设置socketTimeout超时时间
  6. 再次检查是否已aborted连接
  7. 处理认证：org.apache.http.impl.auth.HttpAuthenticator#generateAuthResponse
  8. 执行请求：org.apache.http.protocol.HttpRequestExecutor
    1. 捕获异常：IOException/HttpException/RuntimeException，存在则关闭连接
  9. 执行连接复用策略：org.apache.http.ConnectionReuseStrategy#keepAlive
  10. 如果需要认证：org.apache.http.impl.execchain.MainClientExec#needAuthentication
  11. 如果可以复用，则消费响应体后关闭流
  12. 否则：关闭连接
  13. 处理userToken
  14. 如果响应体HttpEntity为null，或者响应体不是流式响应体org.apache.http.HttpEntity#isStreaming
  15. 释放连接，并返回响应体代理（不包含连接connHolder）：org.apache.http.impl.execchain.HttpResponseProxy#HttpResponseProxy
  16. 否则返回响应体代理（包含连接connHolder）：org.apache.http.impl.execchain.HttpResponseProxy#HttpResponseProxy
  17. 捕获异常
  18. HttpException/IOException/RuntimeException/Error：释放连接
  19. ConnectionShutdownException：不需要释放连接

释放连接

httpclient释放连接场景的总结

  1. 执行请求发生以下异常时，会释放连接
    1. 执行请求期间：IOException/HttpException/RuntimeException
    2. 请求+响应整个过程期间：HttpException/IOException/RuntimeException/Error
  2. 请求完成后，响应体HttpEntity为空时，会释放连接
  3. 请求完成后，响应体不为空但HttpEntity不是流式时，会释放连接
  4. 请求完成后消费完HttpEntity时，会释放连接，例如：EntityUtils.toString(entity)

注意：请求完成后，响应体不为空，且HttpEntity为流式时，不会自动释放连接，需要客户端自行释放连接

生产连接泄漏案例

tomcat:tomcat-embed-core-8.5.72.jar

客户端代码

长轮询线程

new KafkaThread("KM-LONG-POLLING", new LongPollingTask(), true).start();
class LongPollingTask implements Runnable {
    @Override
    public void run() {
        while (true) {
            try {
                int httpResponseCode = RestClient.longPollingStatus(KM_CONFIG_LISTENER_URL);
                if (HttpStatus.SC_CREATED == httpResponseCode) {
                    CONFIG.topicsAndClusterInfo = loadFromKM();
                    CONFIG.version.getAndIncrement();
                    log.info("KM Config Has Change:{} ", CONFIG.topicsAndClusterInfo);
                }
                log.debug("KM long polling .................");
            } catch (Exception e) {
                log.error("KM long polling failed , ", e);
            }
        }
    }
}

请求服务端获取数据

    public static int longPollingStatus(String uri) {

        try {
            HttpResponse httpResponse = LONG_REST_CLIENT.get(uri, HttpResponse.class);
            return httpResponse.getStatusLine().getStatusCode();
        } catch (Exception e) {
        }

        return HttpStatus.SC_BAD_GATEWAY;
    }

HttpClient工具类

  1. socketTimeout：60S
  2. 连接池大小maxPerRoute：2
    public <T> T get(String uri, Class<T> clazz, Map<String, ?> params, Map<String, String> headers) throws RestClientException {
        String aUri = buildUrl(uri, params);
        log.debug("Start GET uri[{}] with params[{}] header[{}]", uri, params, headers);
        String body = null;
        try {
            HttpGet httpGet = buildHttpGet(aUri, headers);
            log.debug("Done GET uri[{}] with params[{}] header[{}], and response is {}", uri, params, headers, body);
            if (clazz == HttpResponse.class) {
                return (T) httpClient.execute(httpGet);
            }
            body = executeRequest(httpGet);
            if (clazz == String.class) {
                return (T) body;
            }
            if (body != null) {
                return JacksonUtil.from(body, clazz);
            }
        } catch (Exception e) {
            log.warn("Occur error when GET uri[{}] with params[{}] headers[{}], response is {}, error: {}", uri, params, headers, body, e);
            throw new RestClientException(e.getMessage(), e);
        }
        return null;
    }

服务端代码

controller

    @RequestMapping("/listener")
    public void fetchTopicAndClusterInfo(@RequestParam String appName,
                                         HttpServletRequest request,
                                         HttpServletResponse response) {
        topicAndClusterInfoManager.addAsyncRequest(renameAppName(appName), request, response);
    }

异步请求

    public void addAsyncRequest(String appName, HttpServletRequest request, HttpServletResponse response) {
        AsyncContext asyncContext = request.startAsync(request, response);
        AsyncTask asyncTask = new AsyncTask(asyncContext, true);
        APPID_CONTEXT.put(appName, asyncTask);

        // 30s 后写入 304 响应
        TIMEOUT_CHECKER.schedule(() -> {
            if (asyncTask.isTimeout()) {
                try {
                    APPID_CONTEXT.remove(appName, asyncTask);
                    response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
                    asyncContext.complete();
                } catch (Exception e) {

                }
            }
        }, 30, TimeUnit.SECONDS);
    }

案例为什么会发生连接泄漏？

案例并非一定会泄漏，生产9台服务，有3台出现了泄漏
案发现场

"KM-LONG-POLLING" #90 daemon prio=5 os_prio=0 cpu=7591.61ms elapsed=3429768.95s tid=0x00007f52e0a86d30 nid=0x11f waiting on condition  [0x00007f52ce2c8000]
   java.lang.Thread.State: WAITING (parking)
	at jdk.internal.misc.Unsafe.park(java.base@11.0.10/Native Method)
	- parking to wait for  <0x00001000bead9b18> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(java.base@11.0.10/LockSupport.java:194)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@11.0.10/AbstractQueuedSynchronizer.java:2081)
	at org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:379)
	at org.apache.http.pool.AbstractConnPool.access$200(AbstractConnPool.java:69)
	at org.apache.http.pool.AbstractConnPool$2.get(AbstractConnPool.java:245)
	- locked <0x00001000de891e20> (a org.apache.http.pool.AbstractConnPool$2)
	at org.apache.http.pool.AbstractConnPool$2.get(AbstractConnPool.java:193)
	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.leaseConnection(PoolingHttpClientConnectionManager.java:304)
	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager$1.get(PoolingHttpClientConnectionManager.java:280)
	at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:190)
	at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
	at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
	at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
	at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
	at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
	at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
	at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
	at ....framework.net.RestClient.get(RestClient.java:315)
	at ....framework.net.RestClient.get(RestClient.java:161)
	at ....framework.net.RestClient.get(RestClient.java:154)
	at ....kafka.core.util.RestClient.longPollingStatus(RestClient.java:31)
	at ....kafka.core.metadata.KafkaMetaDataManager$LongPollingTask.run(KafkaMetaDataManager.java:171)
	at java.lang.Thread.run(java.base@11.0.10/Thread.java:829)

   Locked ownable synchronizers:
	- None

3台机器均处于等待获取连接中，线程为死循环，不应该是waiting状态，并且单线程任务，连接池大小为2，不应该出现等待连接场景。问题基本定位是连接泄漏导致，为什么呢？

客户端超时？
  1. 客户端超时时间为60S
  2. 服务端定时任务为30S，30S左右一定会响应客户端状态码304
  3. 客户端不会超时，排除
客户端没有主动关闭连接？
  1. 正常响应没有HttpEntity，会自动关闭连接，排除
  2. 客户端无论是发生超时异常还是正常获取到数据，httpclient会自动关闭连接，排除
  3. 本地尝试复现，并且对请求抓包，看到服务端果然没有正常响应请求，而是响应了500错误码，并且符合不自动释放连接的场景

问题定位，因为服务端响应5xx错误时会触发连接泄漏。

为什么服务端会响应5xx错误呢？

查看服务端异步请求代码，发现了猫腻-_-!代码如下:org.apache.catalina.connector.Request#startAsync(javax.servlet.ServletRequest, javax.servlet.ServletResponse)

    @Override
    public AsyncContext startAsync(ServletRequest request,
            ServletResponse response) {
        if (!isAsyncSupported()) {
            IllegalStateException ise =
                    new IllegalStateException(sm.getString("request.asyncNotSupported"));
            log.warn(sm.getString("coyoteRequest.noAsync",
                    StringUtils.join(getNonAsyncClassNames())), ise);
            throw ise;
        }

        if (asyncContext == null) {
            asyncContext = new AsyncContextImpl(this);
        }

        asyncContext.setStarted(getContext(), request, response,
                request==getRequest() && response==getResponse().getResponse());
        asyncContext.setTimeout(getConnector().getAsyncTimeout());

        return asyncContext;
    }

没错，tomcat的异步请求实现是有超时时间，而且超时时间恰好是：30S
截屏2023-05-24 23.01.40.png

总结

连接泄漏的原因小结

  1. 客户端没有主动释放连接
  2. 服务端长轮询定时任务刚好是30S与Tomcat的异步请求超时时间30S吻合
  3. 在数据没有准备好时，服务端定时任务（ScheduledThreadPoolExecutor）30S到时调度任务期间，个别任务还未被调度唤醒时，Tomcat异步请求超时，提前响应了客户端，客户端收到异常请求时没有主动关闭连接，导致连接发生泄漏

解决方法

  1. 主动释放连接
  2. 客户端超时时间设置低于30S
  3. 超时监控：起一个定时任务，定期检查连接是否已超时，超时则主动释放

推荐方案3，类似实现可以参考：tomcat-jdbc连接池，其中就有超时驱赶机制

Mall4j商城实战 - 功能分析
yueerba126的博客
11-21 504
spring-aop。
.NET 中 HttpClient 的超时问题
NauClojure的博客
09-22 462
在上面的示例中，我们创建了一个 CancellationTokenSource 对象，并使用 CancelAfter 方法将超时时间设置为 10 秒。在超过指定时间后，HttpClient 将取消挂起的请求并引发相应的异常。在本文中，我们将探讨如何处理 HttpClient 的超时，并提供一些示例代码来帮助您解决这个问题。通过使用这些方法，您可以有效地处理 HttpClient 的超时问题，并确保您的应用程序具有良好的性能和可靠性。在上面的示例中，我们将超时时间设置为 10 秒。
Apache HttpClient连接池泄露问题排查
hdfg159的专栏
09-05 1679
Apache HttpClient连接池泄露问题排查 问题背景 业务系统主要的业务是一个数据聚合管理平台，其中系统有一个功能是同步所有资源（简称 大同步） 业务同步数据请求数据工具是适配 Apache HttpClient 的 Feign ，这种请求封装是我当时根据业务适配业务封装请求 api Feign 版本: 10.10.1 问题来源 在生产环境，大同步功能(20多个任务)发现跑了一半多的任务时候卡住，在测试环境并没有发现这个问题 同步接口 public interface Sync
HttpClient连接池泄露
cainiao1412的博客
02-24 1792
现象 内部提供了一个文件上传的SDK，通过Apache HttpClient访问公司内部的文件服务器进行文件上传，然后偶尔会有同事反馈文件没有上传成功，但是文件服务器这边查看log也并没有收到请求， 比较频繁出现的是，有个小组自己封装了一个导入导出的服务，这个服务会大量频繁的与文件服务打交道，在高峰期的时候，对方导入导出就会大量出现文件无法上传，卡住的情况，查看log就是客户端打印出开始上传，然后线程就没有下文了， 因为sdk没有提供设置connectionTimeout等超时时间的设置，超时时间使用
HTTP连接泄漏示例
还在活水泥的未来包工头
04-18 328
HTTP连接泄漏指的是在使用HTTP连接池时，由于未正确关闭HTTP连接导致连接池中的连接资源无法释放，从而影响连接池中连接的可用性。连接池中连接的数量是有限的，如果连接池中的连接资源被无限制地占用，就会导致连接池中的连接资源不足，从而导致请求超时、性能下降等问题。在上述代码中，每次使用完HTTP响应对象后都会关闭它，并在所有HTTP请求完成后关闭HTTP客户端对象，从而确保连接池中的连接资源得到正确释放，避免HTTP连接泄漏。
关于HttpClient造成的内存泄露问题
最新发布
寒冰屋的专栏
12-29 952
HttpClient可以复用，但在高吞吐的应用中，也应该复用，否则可能造成Socket资源紧张，因为Socket关闭后，根据TCP协议的安全指引，要‘冷处理’一会后，才能被重新使用，Windows下可以是2分钟/4分钟
线上内存泄漏排查全纪录之CloseableHttpAsyncClient
FeelTouch Labs
12-22 3221
目录 前言 疑点restClient在报出异常时没有正确执行关闭导致内存泄漏 关键部分未改动前代码 于是果断修改代码如下，并重新上线 基于源代码分析 分析路线1：经过哪些调用，最终关闭了什么? 分析路线2：这种手动调用是否有必要，不会自动执行资源释放吗？ 最终结论 前言 线上内存报警，重启之后内存占用降低，但是慢慢升高且几乎没有下降迹象，最终流量高峰时触发内存阈值，导致报警，前...
commons-httpclient-3.0-rc4.rar
01-28
4. **内存泄露**：注意及时关闭HttpMethod和HttpClient，防止内存泄漏。 六、实战应用示例 在实际项目中，HttpClient常用于网页抓取、API调用、文件下载等场景。例如，通过PostMethod发送JSON数据到RESTful API，或...
HttpClient入门教程与实战指南
此外，HttpClient 还支持 Cookie 管理、身份验证、连接池管理等功能，使其成为复杂网络环境下的理想选择。 4. **高级特性**： - **重试策略**：HttpClient 允许自定义重试机制，以应对网络不稳定或临时性错误。 -...
commons-httpclient
08-13
1. **连接池管理**：合理配置连接池大小，避免资源浪费和连接泄露。 2. **异常处理**：对HttpClient的异常进行适当处理，确保程序的健壮性。 3. **线程安全**：HttpClient实例不是线程安全的，应为每个请求创建新...
构建可靠性提升！Apache HttpClient故障排查实战指南
Apache HttpClient故障排查实战指南](https://shareprogramming.net/wp-content/uploads/2020/04/thread-pool.png) # 1. Apache HttpClient概述与基础 ## 1.1 HttpClient简介 Apache HttpClient 是Apache软件基金会...
服务之间的http调用越来越多，下面把使用http连接池的注意事项及运遇到的坑和大家分享一下
u011568320的博客
07-14 9440
一、为什么要用Http连接池 1、降低延迟：如果不采用连接池，每次连接发起Http请求的时候都会重新建立TCP连接(经历3次握手)，用完就会关闭连接(4次挥手)，如果采用连接池则减少了这部分时间损耗，别小看这几次握手，本人经过测试发现，基本上3倍的时间延迟 2、支持更大的并发：如果不采用连接池，每次连接都会打开一个端口，在大并发的情况下系统的端口资源很快就会被用完，导致无法建立新的连接 二、代码1
java732_java – 如何诊断泄漏的http连接(org.apache.ht...
weixin_39842029的博客
02-19 195
我有一个在Amazon的EC2上运行的多线程java程序.它使用org.apache.http.impl.client.DefaultHttpClient通过HttpPost和HttpGet从供应商查询和获取数据项.同时,它使用AWS的Java SDK将检索到的数据项推送到S3.运行几天后,我得到通常伴随http连接泄漏的症状：org.apache.http.conn.ConnectionPool...
连接池剖析及连接泄漏定位思路
shuxiaohua的博客
01-12 1698
背景 最近连续解决两起连接泄漏的问题，期间阅读了大量开源源码，发现开源软件中设计的连接池，用的也都是一些常规手段，本文为大家揭开这层神秘的面纱。 概述 大多数应用中应该都是用的TCP协议，TCP连接在建立阶段会经过3次握手，销毁阶段会经过4次握手。标准网络是分7层的，每一层都有各自的协议头，应用层拿到的有效数据，在整个报文中占比没这么大。TCP握手阶段的报文，对应用层来讲都是额外的负担。所以很多客户端都会设计连接池，来复用已建立的连接。减少创建连接带来的消耗。 连接池本身不复杂，如果不想做的通用，少量的代码
解决HttpClient连接未释放导致的新请求失败的问题
Walle的博客
03-31 5239
问题描述 tcp 0 0 0.0.0.0:11235 0.0.0.0:* LISTEN 50557/java tcp 0 0 0.0.0.0:36289 0.0.0.0:* LISTEN 50557/java tcp 0 0 0.0.0.0:8006 0.0.0
httpclient 释放连接的问题 Invalid use of SingleClientConnManager: connection still allocated
weixin_34407348的博客
03-22 200
Invalid use of SingleClientConnManager: connection still allocated httpPost.releaseConnection();  该代码只会复用连接，并不会关闭当前连接，其实下面的方法client.getConnectionManager().closeIdleConnections(0, TimeUnit.MICROSECO...
RestTemplate介绍使用,以及整合 HttpClient 连接池 配置长连接
热门推荐
zzhongcy的专栏
02-28 1万+
1、RestTemplate介绍 spring框架提供的RestTemplate类可用于在应用中调用rest服务，它简化了与http服务的通信方式，统一了RESTful的标准，封装了http链接，我们只需要传入url及返回值类型即可。相较于之前常用的httpClient，RestTemplate是一种更优雅的调用RESTful服务的方式。 RestTempla...
Java Http请求造成服务器服务端口大量CLOSE_WAIT无法释放的解决办法
liuxinzhi1982的专栏
09-20 4079
在项目开发中使用HTTP请求和服务程序交互数据，部署在云服务器后有一次发现系统资源异常，检查后发现问题如下图： 在8019端口上有大量的CLOSE_WAIT释放非常缓慢。 开始查问题，定位到如下代码： HttpConnectionManager httpConnectionManager = new MultiThreadedHttpConnectionManager(); 这样定...
一次线上故障：数据库连接池泄露后的思考
Park33的博客
08-11 1734
早上作为能效平台系统的使用高峰期，系统负载通常比其它时间段更大一些，某个时间段会有大量用户登录。当天系统开始有用户报障，发布系统线上无法构建发布，然后后续有用户不能登录系统，系统发生假死，当然系统不是真的宕机，而是所有和数据库有关的连接都被阻塞，随后查看日志发现有大量报错。可以看出上面的报错和数据库连接有关，大量超时。通过对线上debug日志的分析，也验证了数据库连接池被大量消耗。这是开始大量报错前的日志。...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值