Jersey 客户端连接关闭内存泄漏问题
我正在使用 Jersey v10 并编写了以下代码。这是关闭 Jersey 客户端连接以避免内存泄漏的正确方法吗？在此之前我没有对他进行任何调用。
ClientConfig config = setupHttps();
final Client c = Client.create(config);
final WebResource r = c.resource(baseUri);
ClientResponse response = null;
try {
response = r.path("/....")
.header("contentId", id)
.header("sid", sid).get(ClientResponse.class);
...
} catch (Exception e) {
log.error("Error returning contentServiceName.");
} finally {
if (response != null) {
response.close();
}
if (c!= null) {
c.destroy();
}
}
TIA， 维杰
I am using Jersey v10 and have written the following code.Is this the right way to close a Jersey client connection to avoid memory leaks.I was not doing any calls int he finally before this.
ClientConfig config = setupHttps();
final Client c = Client.create(config);
final WebResource r = c.resource(baseUri);
ClientResponse response = null;
try {
response = r.path("/....")
.header("contentId", id)
.header("sid", sid).get(ClientResponse.class);
...
} catch (Exception e) {
log.error("Error returning contentServiceName.");
} finally {
if (response != null) {
response.close();
}
if (c!= null) {
c.destroy();
}
}
TIA,
Vijay
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
据我所知，是的，这是关闭泽西岛客户的正确方法......但有以下警告。
1）您试图防止的不是内存泄漏，而是连接（到您正在寻址的服务器）泄漏...
2）以下内容是关于 Client 泽西岛手册第 3 章：
因此，如果您计划进行多个调用，最好不要为每个调用调用 destroy 。对于 WebResources 来说也是如此（但程度较小）。
3）我所描述的是泽西岛1.1（但我看到到目前为止有关此的线程回到 2009 年）。
As far as I know, yes, this is the right way to close a Jersey client ... with the following caveats.
1) What you're trying to prevent is not memory leaks, but connection (to the server you're addressing) leaks ...
2) The following is written about the Client class in Chapter 3 of the Jersey Handbook:
Therefore, if you're planning on making multiple calls, it's a good idea not to call destroy for every call. The same (but to a lesser extent) is true for WebResources.
3) What I'm describing is from Jersey 1.1 (but I see threads about this as far back as 2009).