[JAVA] À propos de disconnect () de HttpURLConnection

introduction

Récemment, j'écrivais du code comme le suivant Sample.java à la maison.

Sample.java


HttpURLConnection urlconn = null;
PurchaseItemInfo itemInfo = null;
try {
    URL url = new URL([URL]);
    urlconn = (HttpURLConnection) url.openConnection();
    urlconn.setRequestMethod("GET");
    urlconn.setInstanceFollowRedirects(false);
    urlconn.connect();

    try (InputStreamReader inReader = new InputStreamReader(urlconn.getInputStream());
            BufferedReader reader = new BufferedReader(inReader);) {
        doSomething();
    }
} finally {
    urlconn.disconnect();
}

Pendant que j'écrivais ceci, je regardais dans HttpURLConnection, mais à la fin j'ai trouvé à la fois un exemple appelant disconnect () et un exemple ne l'appelant pas. Normalement, si vous ouvrez () une ressource (FileInputStream ou Connection), puis essayez avec des ressources pour la fermer automatiquement, ou la fermez explicitement () dans la clause finally, elle occupera la ressource jusqu'à ce qu'elle devienne la cible de GC. Je pensais que c'était une règle de base de toujours fermer (). Je pensais que c'était la même chose pour HttpURLConnection, mais je ne peux pas utiliser try-with-resources car je n'ai pas implémenté l'interface AutoCloseable. .com / taumax / items / 1e3b03771fe73adfaf95 # 20191111-% E3% 81% 94% E6% 8C% 87% E6% 91% 98% E3% 82% 92% E3% 81% 84% E3% 81% 9F% E3% 81% A0% E3% 81% 84% E3% 81% 9F% E3% 81% AE% E3% 81% A7% E4% BF% AE% E6% AD% A3) Est-ce un peu différent? J'ai commencé à réfléchir, alors j'ai cherché.

Différence entre disconnect () de HttpURLConnection et close () de ressource

HttpURLConnection (spécification API) indiqué comme suit.

Chaque instance HttpURLConnection est utilisée lors d'une seule requête, mais la connexion réseau au serveur HTTP derrière elle peut être partagée de manière transparente avec d'autres instances. L'appel de la méthode close () sur InputStream ou OutputStream de HttpURLConnection après la demande peut libérer les ressources réseau associées à cette instance, mais n'a aucun impact sur la connexion persistante partagée. .. Lorsque vous appelez la méthode disconnect (), le socket que vous utilisiez pouvait être fermé si la connexion persistante était inactive à ce moment-là.

En plus de cela, quand j'ai regardé les sites que j'ai écrits pour référence, si je déconnecte () HttpURLConnection, il y a une possibilité que la socket soit fermée même si elle est inactive avec le paramètre KeepAlive. (HttpURLConnection est le keepalive par défaut)

Si vous fermez () InputStream / OutputStream au lieu de déconnecter () HttpURLConnection, les ressources réseau seront libérées, mais le socket ne sera pas fermé et sera réutilisé. Il paraît que. Si vous faites une petite chose par vous-même comme cette fois-ci, vous n'avez pas besoin d'en être conscient, mais si vous avez un système où de nombreuses personnes se connectent / se déconnectent à plusieurs reprises pour des raisons telles que la connexion, sachez-le correctement. Si vous ne le codez pas, cela peut entraîner le pire problème de performances ... J'ai appris une chose.

référence

HttpURLConnection # disconnect and Keep-Alive

2019/11/11 Corrigé parce que vous l'avez souligné

"Je pensais que c'était la même chose pour HttpURLConnection dans l'introduction" de cet article, mais je ne peux pas utiliser try-with-resources car je n'ai pas implémenté l'interface AutoCloseable. " Vous avez souligné cette partie.

AutoCloseable est une interface fonctionnelle et peut également être implémentée dans des expressions lambda.

HttpURLConnection urlconn = (HttpURLConnection) url.openConnection(); try (AutoCloseable c = () -> urlconn.disconnect()) { doSomething(); }

Certes, AutoCloseable n'a qu'une méthode close (), vous pouvez donc utiliser des expressions lambda. .. .. Vous pouvez donc également écrire:

Sample.java


URL url = new URL([URL]);
HttpURLConnection urlconn = (HttpURLConnection) url.openConnection();
urlconn.setRequestMethod("GET");
urlconn.setInstanceFollowRedirects(false);

PurchaseItemInfo itemInfo = null;
try (AutoCloseable c = () -> urlconn.disconnect();
        InputStreamReader inReader = new InputStreamReader(urlconn.getInputStream());
        BufferedReader reader = new BufferedReader(inReader);) {

    urlconn.connect();
    doSomething();
}

Merci d'avoir souligné. J'ai beaucoup appris.

c'est tout.

Recommended Posts

À propos de disconnect () de HttpURLConnection
À propos de la sélection d'OpenJDK
À propos de DI of Spring ①
À propos de DI of Spring ②
À propos de form. ○○ de form_with
À propos de la gestion de Null
À propos des instances Java
À propos du fonctionnement simple de Docker
À propos de la description de Docker-compose.yml
À propos de la comparaison de taille de compareTo
À propos des types de couverture de code
Mémorandum sur LOD.
À propos de la correspondance partielle du sélecteur
À propos des bases du développement Android
À propos de Biocontainers fastqc et Java
À propos de Lambda, Stream, LocalDate de Java8
À propos de la gestion des erreurs de la fonction de commentaire
[Rails] À propos de la mise en œuvre de la fonction similaire
A propos de la liaison de l'annotation Spring AOP
À propos du rôle de la méthode initialize
À propos de removeAll et de retentionAll de ArrayList
Pensez aux 7 règles d'Optionnel
À propos =
À propos du téléchargement d'images de jsp (servlet)
À propos du cache disque de la série Glide 4
Explique les objets Ruby Array
À propos du niveau de journalisation de java.util.logging.Logger
Qu'est-ce qu'un test? ・ À propos de l'importance d'un test
[Rails 6.0] À propos de la sauvegarde par lots de plusieurs enregistrements
À propos du fonctionnement de next () et nextLine ()
À propos de l'affichage initial de Spring Framework
[Java débutant] À propos de l'initialisation d'un tableau multidimensionnel
[Connaissance de base de Java] À propos de la conversion de type
À propos du traitement de BigDecimal (avec réflexion)
À propos du nombre de threads de Completable Future