Calling 'java.util.zip.Deflater.finish()' prematurely hangs the application.
The application is spinning consuming one cpu.


1. JDK-6368025
--------------
The behaviour is known in JDK-6368025:

 http://bugs.java.com/view_bug.do?bug_id=6368025_
 JDK-6368025
 GZIPOutputStream.finish() does Not work
 Resolution: Not an Issue

In JDK-6368025 it was suggested to document this with the API.
This has not yet happened.

2. Docs
-------
Here is Java SE documentation:

2.1 java.util.zip.Deflater
--------------------------
2.1.1 Java SE 6
---------------
http://docs.oracle.com/javase/6/docs/api/java/util/zip/Deflater.html#finish%28%29

--------------------------------------------------
 finish
public void finish()
    When called, indicates that compression should end with the current contents of the input buffer.
--------------------------------------------------

2.1.2 Java SE 7
---------------
http://docs.oracle.com/javase/7/docs/api/java/util/zip/Deflater.html#finish%28%29

--------------------------------------------------
    finish
    public void finish()
    When called, indicates that compression should end with the current contents of the input buffer.
--------------------------------------------------

2.1.3 Java SE 8
---------------
http://docs.oracle.com/javase/8/docs/api/java/util/zip/Deflater.html#finish--

--------------------------------------------------
    finish
    public void finish()
    When called, indicates that compression should end with the current contents of the input buffer.
--------------------------------------------------

2.2 java.util.zip.GZIPOutputStream
----------------------------------

http://docs.oracle.com/javase/8/docs/api/java/util/zip/GZIPOutputStream.html#finish--
--------------------------------------------------
public void finish()
            throws IOException
Finishes writing compressed data to the output stream without closing the underlying stream.
Use this method when applying multiple filters in succession to the same output stream.
Overrides:
    finish in class DeflaterOutputStream
Throws:
    IOException - if an I/O error has occurred
--------------------------------------------------

3. Behaviour
------------
The behaviour is strictly reproducible with Java SE 6, 7, 8 and 9 EA:

3.1 Behaviour w/ Java SE 6
--------------------------
% /jdk1.6.0_81/bin/java -version
java version "1.6.0_81"
Java(TM) SE Runtime Environment (build 1.6.0_81-b08)
Java HotSpot(TM) Server VM (build 20.81-b05, mixed mode)
% /jdk1.6.0_81/bin/javac ZStreamRefHangDemo.java
% /jdk1.6.0_81/bin/java ZStreamRefHangDemo

----------------- Java thread dump -----------------------------
2014-10-13 12:58:00
Full thread dump Java HotSpot(TM) Server VM (20.81-b05 mixed mode):
[...]
"main" prio=3 tid=0x0002fc00 nid=0x2 runnable [0xfe37f000]
    java.lang.Thread.State: RUNNABLE
  at java.util.zip.Deflater.deflateBytes(Native Method)
  at java.util.zip.Deflater.deflate(Deflater.java:306)
  - locked <0xe6430838> (a java.util.zip.ZStreamRef)
  at java.util.zip.Deflater.deflate(Deflater.java:319)
  at ZStreamRefHangDemo.runDeflate(ZStreamRefHangDemo.java:46)
  at ZStreamRefHangDemo.main(ZStreamRefHangDemo.java:18)

     Locked ownable synchronizers:
  - None
-------------------------------------------------------------------

% ps -ef | grep java
  user 14378 4318 35 12:53:23 pts/10 0:26 /data/jdk1.6.0_81/bin/java ZStreamRefHangDemo

Using '/usr/bin/prstat -L' shows

  PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/LWPID
 14378 user 107M 28M run 20 0 0:02:22 48% java/2


3.2 Behaviour w/ Java SE 9
--------------------------
3.2.1 Demo
----------
The behaviour is strictly reproducible with Java SE 9 EA:

% /jdk1.9.0/bin/java -version
java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-b34)
Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b34, mixed mode)
%
% /jdk1.9.0/bin/javac ZStreamRefHangDemo.java
% /jdk1.9.0/bin/java ZStreamRefHangDemo

3.2.2 Java Thread dump
----------------------
Thread (nid) 2 is of interest:

----------------- Java thread dump -----------------------------

2014-10-10 08:45:04
Full thread dump Java HotSpot(TM) 64-Bit Server VM (1.9.0-ea-b34 mixed mode):
[...]
"main" #1 prio=5 os_prio=64 tid=0x000000010010e800 nid=0x2 runnable [0xffffffff7b4ff000]
   java.lang.Thread.State: RUNNABLE
        at java.util.zip.Deflater.deflateBytes(Native Method)
        at java.util.zip.Deflater.deflate(Deflater.java:442)
        - locked <0xffffffff42eac990> (a java.util.zip.ZStreamRef)
        at java.util.zip.Deflater.deflate(Deflater.java:383)
        at ZStreamRefHangDemo.runDeflate(ZStreamRefHangDemo.java:48)
        at ZStreamRefHangDemo.main(ZStreamRefHangDemo.java:20)

   Locked ownable synchronizers:
        - None
-------------------------------------------------------------------

3.2.3 Application is spinning
-----------------------------
% ps -ef | grep java
  user 12127 12126 48 08:39:56 pts/16 11:44 /data/jdk1.9.0/bin/java ZStreamRefHangDemo
[ after some time ...]
% ps -ef | grep java
  user 12127 12126 47 Oct 10 pts/16 4289:39 /data/jdk1.9.0/bin/java ZStreamRefHangDemo
%

On a dual-cpu box, thread #2 is consuming one cpu.

Using '/usr/bin/prstat -L' shows

   PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/LWPID
 12127 user 301M 104M cpu1 0 0 0:10:06 48% java/2

  PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/LWPID
 12127 user 914M 529M cpu1 30 0 0:34:36 41% java/2

  PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/LWPID
 12127 user 726M 663M cpu0 0 0 2:22:28 42% java/2

   PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/LWPID
 12127 user 622M 567M cpu1 0 0 3:20:02 40% java/2

   PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/LWPID
 12127 user 442M 396M cpu1 0 0 66:34:44 44% java/2