I have a parallel question.
let's assume the following method which is running by a thread(A).
void run(){
//some work
FileInputStream fis=new FileInputStream(new File("/home/share/_config"));
//some work with fis
}
and assume there is a error which is not catchable, so as I got from java threading, we can add a uncaught exception manager with setUncaughtExceptionHandler() method, so the question is, how would I access the file I opened (fis) from the killed thread stack and close it from the handler?
NOTE: Code works in Java 7+
Don't do this! Usually, the method that opens a stream should also close it! Put the stream in a try-with-resource clause, then it will be closed automatically:
void run() {
//some work
try (FileInputStream fis=new FileInputStream(new File("/home/share/_config"))) {
//some work with fis
}
}
The stream fis will be closed, if the execution flow leaves the try block - either because it finishes its work or due to an exception.
It is also possible to open multiple input streams in the same try-with-resource clause by using a semicolon (;) as separator. See http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html for details.
Related
I saw this example, and I didn't see the close() method invoked on the InputStream, so would prop.load() close the stream automatically? Or is there a bug in the example?
The Stream is not closed after Properties.load ()
public static void main(String[] args) throws IOException {
InputStream in = new FileInputStream(new File("abc.properties"));
new Properties().load(in);
System.out.println(in.read());
}
The above code returns "-1" so the stream is not closed. Otherwise it should have thrown java.io.IOException: Stream Closed
Why do you ask when the javadoc of Properties.load(InputStream inStream) says this?
The specified stream remains open after this method returns.
It has been saying that since Java 6.
As EJP said in a comment: Don't rely on arbitrary Internet junk. Use the official Oracle Java documentation as your primary source of information.
The following try-with-resources will close the InputStream automatically (you can add catch and finally if needed):
try (InputStream is = new FileInputStream("properties.txt")) {
// is will be closed automatically
}
Any resource declared within a try block opening will be closed. Hence, the new construct shields you from having to pair try blocks with corresponding finally blocks that are dedicated to proper resource management.
Article by Oracle here: http://www.oracle.com/technetwork/articles/java/trywithresources-401775.html.
In my API (Spring boot) I have an endpoint where users can upload multiple file at once. The endpoint takes as input a list of MultipartFile.
I wish not to directly pass this MultipartFile object to the service directly so I loop through each MultipartFile and create a simple map that stored the filename and its InputStream.
Like this:
for (MultipartFile file : files) {
try (InputStream is = multipartFile.getInputStream()) {
filesMap.put(file.getOriginalFilename(), is);
}
}
service.uploadFiles(filesMap)
My understanding for Java streams and streams closing is quite limited.
I thought that try-with-resources automatically closes the InputStream once the code reached the end of the try block.
In the above code when does exactly the the multipartFile.getInputStream() gets closed?
The fact that I'm storing the stream in a map will that cause a memory leak?
Stream closes right after execution reaches closing bracket of try block.
It is okay to store InputStream anywhere after you closed it.
But be aware of that you can't read anything from this stream after you closes it.
Thanks to comments
Also, be aware of that some streams have special behavior on close() and it always depends on Stream realization.
For example:
If you try to read from closed FileInputStream you will get
java.io.IOException: Stream Closed
If you try to read from closed ByteArrayInputStream it will be okay, because of it's special close() realization: public void close() throws IOException {}
When does exactly the multipartFile.getInputStream() gets closed?
try (InputStream is = multipartFile.getInputStream()) {
filesMap.put(file.getOriginalFilename(), is);
} // <-- here
The try-with-resources statement ensures that each resource is closed at the end of the statement.
The fact that I'm storing the stream in a map will that cause a memory leak?
No, your collection just keeps closed InputStreams and you won't be able to read from them (in addition, you will get IOException).
Today, when I was working on some kind of servlet which was writing some information to some file present on my hard disk, I was using the following code to perform the write operation
File f=new File("c:/users/dell/desktop/ja/MyLOgs.txt");
PrintWriter out=new PrintWriter(new FileWriter(f,true));
out.println("the name of the user is "+name+"\n");
out.println("the email of the user is "+ email+"\n");
out.close(); //**my question is about this statement**
When I was not using the statement, the servlet was compiling well, but it was not writing anything to the file, but when I included it, then the write operation was successfully performed. My questions are:
Why was the data not being written to the file when I was not including that statement (even my servlet was compiling without any errors)?
Up to which extent the close operation is considerable for the streams?
Calling close() causes all the data to be flushed. You have constructed a PrintWriter without enabling auto-flush (a second argument to one of the constructors), which would mean you would have to manually call flush(), which close() does for you.
Closing also frees up any system resources used by having the file open. Although the VM and Operating System will eventually close the file, it is good practice to close it when you are finished with it to save memory on the computer.
You may also which to put the close() inside a finally block to ensure it always gets called. Such as:
PrintWriter out = null;
try {
File f = new File("c:/users/dell/desktop/ja/MyLOgs.txt");
out = new PrintWriter(new FileWriter(f,true));
out.println("the name of the user is "+name+"\n");
out.println("the email of the user is "+ email+"\n");
} finally {
out.close();
}
See: PrintWriter
Sanchit also makes a good point about getting the Java 7 VM to automatically close your streams the moment you don't need them automatically.
When you close a PrintWriter, it will flush all of its data out to wherever you want the data to go. It doesn't automatically do this because if it did every time you wrote to something, it would be very inefficient as writing is not an easy process.
You could achieve the same effect with flush();, but you should always close streams - see here: http://www.javapractices.com/topic/TopicAction.do?Id=8 and here: http://docs.oracle.com/javase/tutorial/jndi/ldap/close.html. Always call close(); on streams when you are done using them. Additionally, to make sure it is always closed regardless of exceptions, you could do this:
try {
//do stuff
} finally {
outputStream.close():
}
It is because the PrintWriter buffers your data in order for not making I/O operations repeatedly for every write operation (which is very expensive). When you call close() the Buffer flushes into the file. You can also call flush() for forcing the data to be written without closing the stream.
Streams automatically flush their data before closing. So you can either manually flush the data every once in a while using out.flush(); or you can just close the stream once you are done with it. When the program ends, streams close and your data gets flushed, this is why most of the time people do not close their streams!
Using Java 7 you can do something like this below which will auto close your streams in the order you open them.
public static void main(String[] args) {
String name = "";
String email = "";
File f = new File("c:/users/dell/desktop/ja/MyLOgs.txt");
try (FileWriter fw = new FileWriter(f, true); PrintWriter out = new PrintWriter(fw);) {
out.println("the name of the user is " + name + "\n");
out.println("the email of the user is " + email + "\n");
} catch (IOException e) {
e.printStackTrace();
}
}
PrintWriter buffers the data to be written so and will not write to disk until its buffer is full. Calling close() will ensure that any remaining data is flushed as well as closing the OutputStream.
close() statements typically appear in finally blocks.
Why the data was not being written to the file when I was not including that statement?
When the process terminates the unmanaged resources will be released. For InputStreams this is fine. For OutputStreams, you could lose an buffered data, so you should at least flush the stream before exiting the program.
I am working as a trainee in Test Automation.
I am working with creating Junit code with Eclipse and run using Eclipse.
In that I am retriving the datas from excel sheet using FileInputStream function.
FileInputStream fi=new FileInputStream("c:\\search.xls");
Workbook w=Workbook.getWorkbook(fi);
Sheet s=w.getSheet(0);
Is it necessary to close the Inputstream function? If it so please guide me with some codings.
Yes, you need to close the inputstream if you want your system resources released back.
FileInputStream.close() is what you need.
You either need to close(), or end your program.
However you can run into confusing issues if you don't close the file as
sometimes test are run individually or a group of test are run in the same process. (So you could have a test which works one way but not the other)
you cannot rename or delete an open file.
It is best practice to always close your resources which you are finished with them, however I see unit tests as scripts which don't always have to follow best practice.
FileInputStream fi=null;
try {
fi=new FileInputStream("c:\\search.xls");
Workbook w=Workbook.getWorkbook(fi);
Sheet s=w.getSheet(0);
} finally {
if (fi!=null) {
fi.close();
}
}
Yes! you should always release the resources once after you are done with them. Java has a powerful mechanism for Garbage Collection(note that it is different thing compare to resource management/leaks.)
So a Garbage collector can not determine that if you need the resource in future or not? Failing to release resources may cause issues like- Denial of services, poor performance .
As already answered but another effort less way is try with resources
try (FileInputStream fi = new FileInputStream("c:\\search.xls")) {
//do something with fi.
//fi.getChannel() ;
} catch(IOException e) {
// exception handling.
} finally {
// some statements for finally.
}
Now you don't need to explicitly call fi.close() method.
It's always a good idea to close resources you use, BUT:
If you use resource A in resource B, it's sensible to close B instead of A if it has a method for it.
In your case, you use FileInputStream in Workbook, so you'd better to close Workbook and rely on Workbook that it will close FileInputStream.
In this particular case, actually, Workbook will close FileInputStream at the end of the getWorkbook() method but it's still a good idea to close Workbook to be able to be garbage collected.
Recently, when I tried to refactor my code, I had to move the workbook creation to another method, and the FileInputStream is created in that method. That method creates a FileInputStream and returns a Workbook. But FileInputStream is not visible from the main method; so how will I close my FileInputStream at the end of main method? The answer is, you don't have to close FileInputStream, instead you just close the workbook, which internally closes FileInputStream. In short, it is incorrect to say that you must close FileInputStream no matter what.
I do such a way to ensure to close the excel file input stream, this maybe helps
abstract int workWithWorkBook(Workbook workBook);
protected int doWorkBook(Path excelFile) throws IOException {
File f = excelFile.toFile();
try (FileInputStream excelContent = new FileInputStream(excelFile.toFile())){
POIFSFileSystem fileSystem = new POIFSFileSystem(excelContent);
Workbook workBook = null;
if (f.getName().endsWith("xls")) {
workBook = new HSSFWorkbook(fileSystem);
} else if (f.getName().endsWith("xlsx")) {
workBook = new XSSFWorkbook(excelContent);
}
return workWithWorkBook(workBook);
}catch (Exception e){
e.printStackTrace();
throw e;
}
}
9b9ea92b-5b63-47f9-a865-fd40dd602cd5
Do something like this.
FileInputStream fi=null;
try{
fi = new FileInputStream("c:\\search.xls");
Workbook w=Workbook.getWorkbook(fi);
Sheet s=w.getSheet(0);
}catch(IOException ioe){
}finally{
if(fi != null){
fi.close();
}
fi = null;//This will be hint to get finalize() called on fi so that underlying resources used will released like files opened.
}
The Workbook implements the Closeable interface which indicates that you should call the close() method or use a try with resources to free resources acquired by a Workbook object.
You can’t conclude anything on how the InputStream resource is used by the Workbook by simply observing that the Workbook has a close() method.
What really goes on is that the Workbook constructor uses the stream to initialize itself. The constructor does not keep a reference to the stream. The Workbook constructor does not close the InputStream. It is your responsibility to close the InputStream and you can do this immediately after the Workbook object is constructed. The following code is therefore OK:
private static Workbook getWorkbook() throws IOException {
try (InputStream is = ...) {
return WorkbookFactory.create(is); // newer API
}
}
try (Workbook workbook = getWorkbook()) {
Sheet sheet = workbook.getSheet("SheetName");
...
}
Basic CompSci 101 tell us to make sure to close resources that we open, in Java or any language. So yes, you need to close them. Bad juju is bound to happen when you do not do so.
Also, you should learn (and have the inclination) to use the Javadocs. Look up at the Javadoc for FileInputStream and Closeable. The answers are there.
I'm trying to delete a file that another thread within my program has previously worked with.
I'm unable to delete the file but I'm not sure how to figure out which thread may be using the file.
So how do I find out which thread is locking the file in java?
I don't have a straight answer (and I don't think there's one either, this is controlled at OS-level (native), not at JVM-level) and I also don't really see the value of the answer (you still can't close the file programmatically once you found out which thread it is), but I think you don't know yet that the inability to delete is usually caused when the file is still open. This may happen when you do not explicitly call Closeable#close() on the InputStream, OutputStream, Reader or Writer which is constructed around the File in question.
Basic demo:
public static void main(String[] args) throws Exception {
File file = new File("c:/test.txt"); // Precreate this test file first.
FileOutputStream output = new FileOutputStream(file); // This opens the file!
System.out.println(file.delete()); // false
output.close(); // This explicitly closes the file!
System.out.println(file.delete()); // true
}
In other words, ensure that throughout your entire Java IO stuff the code is properly closing the resources after use. The normal idiom is to do this in the try-with-resources statement, so that you can be certain that the resources will be freed up anyway, even in case of an IOException. E.g.
try (OutputStream output = new FileOutputStream(file)) {
// ...
}
Do it for any InputStream, OutputStream, Reader and Writer, etc whatever implements AutoCloseable, which you're opening yourself (using the new keyword).
This is technically not needed on certain implementations, such as ByteArrayOutputStream, but for the sake of clarity, just adhere the close-in-finally idiom everywhere to avoid misconceptions and refactoring-bugs.
In case you're not on Java 7 or newer yet, then use the below try-finally idiom instead.
OutputStream output = null;
try {
output = new FileOutputStream(file);
// ...
} finally {
if (output != null) try { output.close(); } catch (IOException logOrIgnore) {}
}
Hope this helps to nail down the root cause of your particular problem.
About this question, I also try to find out this answer, and ask this question and find answer:
Every time when JVM thread lock a file exclusively, also JVM lock
some Jave object, for example, I find in my case:
sun.nio.fs.NativeBuffer
sun.nio.ch.Util$BufferCache
So you need just find this locked Java object and analyzed them and
you find what thread locked your file.
I not sure that it work if file just open (without locked exclusively), but I'm sure that is work if file be locked exclusively by Thread (using java.nio.channels.FileLock, java.nio.channels.FileChannel and so on)
More info see this question