closeしていません。GCによってcloseされないのか?と思うかもしれません。GCによってcloseされるのはFileInputStreamだけ(あとはFileOutputStream)です。FileInputStreamはfinalizeでcloseする事を仕様として定めていますが、FileReaderは仕様として定めていません。Readerともに仕様にありません。OpenJDK)を見ても、finalize処理は実装されていません。※ちょっと嘘書きました。FileInputStreamしていますのでGCでcloseされます)ちょっと横道にずれますが、.pipeoutファイルってdeleteOnExitしているんですよね。このファイルは毎回異なるファイル名で作成しているので、コネクションをはる度に解放されないオブジェクトが溜まっていきます(まぁメモリリークしているわけですが、定義的にメモリリークと言って良いのかわかんない)。HiveServerのclean処理で.pipeoutファイルをdeleteしても、deleteOnExitのリスト(正確にはLinkedHashSet)からは消えないままです。BugID忘れた&調べる気ない(・x・)次に.txtファイルについて。これってLog4jで出力しているファイルの事なのかな?(デフォの設定だと、.logなので違うファイル?)こっちはまだ調べていませんが、Log4jのFileAppenderの場合、ファイル名を設定する度に1つ前に開いていたFile(というかWriter)をcloseする処理が入っているところまでは確認済み。HiveのExevDriverで以下のように書いていて、これってFileAppenderのreset処理呼ばれるっけ・・。疑問に思ったところで、こっちはいったん調査終了。PropertyConfigurator.configure(hive_l4j);たぶんこっちの事かな・・。hive_job_log_(sessionId)_(乱数).txt。こっちの場合は、HiveHistoryというクラスが担当で、PrintWriterを介してファイルをOpenしており、close処理がfinalizeで呼ばれています。このHiveHistoryはSessionStateのstartメソッドでインスタンス化されます。SessionStateはThreadLocalに保存されます。HiveHistoryはSessionStateが保持しています。思ったけど保持はしていないです。Thriftがどういうモデルなのか分からないですが、仮に接続毎にスレッドを生成しているのであれば、接続がきれた時にSessionStateがThreadLocalから消えて他のどこからも参照がない場合(これはまだ確認してない)、SessionStateはGCの対象になります。その時にHiveHistoryへの参照が全て無くなるので、GC対象となるはずです。仮定が多くて調査になっていないですね(=w=;)jmapとjhatでどういう状態になっているか確認すれば良いだけなのですけどね。お腹すいたのでいったん調査終了(・ω・)※(追記)当たり前の事なのでわざわざ書いてませんでしたが、一応捕捉しておきます。別にGCまかせにすることを推奨とも良しともしていないです。(そんな事一言も書いてないですよね(>ω<))原因となりうるかと、それを良しとするかは軸が違うと思うのです。(さらに追記)FindBugsで解析をすると分かるらしいです。