readline() returns null in Java

2019-02-27 15:59发布

问题:

I'm trying to read the stdin in my Java program. I'm expecting a series of numbers followed by newlines, like:

6  
9  
1  

When providing the input through the eclipse built-in console, everything goes well. But when using the Windows command line, the program prints:

Received '6'.  
Received 'null'.  
Invalid input. Terminating. (This line is written by another function that does an Integer.parseint()).  

My code is:

static String readLineFromStdIn(){  
try{  
        java.io.BufferedReader stdin = new java.io.BufferedReader(new java.io.InputStreamReader(System.in));  
        String input = new String();  
        input = stdin.readLine();  
        System.out.println("Received '" + input + "'");  
        return(input);  
    }catch (java.io.IOException e) {  
        System.out.println(e);   
    }  
    return "This should not have happened";  
}  

Any clues?

回答1:

That you get a null indicates that the relevant Reader objects reached an EOF (end of file), or in other words that they can't get any more standard input. Now the obvious issues with your code are:

  1. Each method call to readLineFromStdIn() will create a new BufferedReader.
  2. Each such BufferedReader will be “competing” with each other for the same, shared input from System.in
  3. And none of these BufferedReader objects are ever properly closed, so your program leaks I/O resources with each call to readLineFromStdIn().

The solution is to use a single shared BufferedReader object for each invocation of readLineFromStdIn().



回答2:

Not really a new answer to this question, but I wanted to clear up confusion in the comments about why the original code behaved as it did (I can't comment because I'm new to ST and haven't garnered reputation points).

The null result has nothing to do with garbage collection. The following program suffers exactly the same fate even though both readers still live, accessible objects:

BufferedReader r1 = new BufferedReader(new InputStreamReader(System.in));
System.out.println(r1.readLine());
BufferedReader r2 = new BufferedReader(new InputStreamReader(System.in));
System.out.println(r2.readLine());

It all comes down to what "Buffered" means in BufferedReader. It's a Reader that includes internal buffering. The internal buffering usually significantly improves the efficiency of operations on the underlying stream, e.g. by attempting to read a full buffer's worth each time, rather than nickle-and-diming the stream to death getting a few bytes here and a few there.

So what happens when you create the first BufferedReader on stdin and read a line from it? That BufferedReader reads a buffer-full from the stream, detects the end of line, returns the first line, and hangs on to the rest of the buffer to fill its next request. That leaves the underlying stream positioned beyond the end of that first line. And if your input is small, it could easily be positioned at EOF.

So now you come along and create a second BufferedReader atop the same stream - which is at EOF - and attempt to get a line. The second BufferedReader attempts to read from the underlying stream and detects EOF, so readLine returns null.