There have been several attempts to fix FilterOutputStream.close, but a casual look reveals that close() has an obvious data race when close is called by separate threads.  

    public void close() throws IOException {
        if (closed) {
            return;
        }
        closed = true;

This is a problem because FilterOutputStream makes no effort to be thread-safe but its subclasses like BufferedOutputStream do, without overriding close.  Maybe it's just too hard to have a thread-unsafe superclass with thread-safe subclasses?  One is tempted to rewrite classes like BufferedOutputStream without using any of the FilterOutputStream helper methods!

This race is likely to be mostly benign in practice.  I investigated this because we see TSAN warnings in jdk8.  There's no closed field in jdk8, but the fundamental problem of implementing close so that it works with thread-safe and thread-unsafe subclasses remains.