When Use FileChannel to read()/write() files?
I am reading the book Thinking in Java, which explains the java.nio.* package and says that NIO is faster than reading and writing files with traditional IO streams. Why?
I have reviewed the following information:
IO stream is byte oriented, traditional IO processing unit is byte, and NIO processing unit is block (byte array), but I think traditional IO can also directly process block (byte array) through BufferedFile*, and traditional IO also has direct Method of processing byte array
private native int readBytes(byte b, int off, int len) throws IOException;
IO is blocking read, NIO can be non-blocking, but I found that the file NIO can only be non-blocking, then NIO has no advantage.
I think the need to use NIO is generally other advantages that need to use NIO, such as:
transferTo()/transferFrom()
So, when should I use NIO for file reading and writing? Why is it faster than traditional IO? What is the correct way to use it? Should I use IO or NIO only when reading and writing files?
java nio java-io
edited Nov 15 '18 at 3:14
user207421
261k25208352
asked Nov 15 '18 at 2:27
CitronCitron
122
add a comment |
I am reading the book Thinking in Java, which explains the java.nio.* package and says that NIO is faster than reading and writing files with traditional IO streams. Why?
I have reviewed the following information:
IO stream is byte oriented, traditional IO processing unit is byte, and NIO processing unit is block (byte array), but I think traditional IO can also directly process block (byte array) through BufferedFile*, and traditional IO also has direct Method of processing byte array
private native int readBytes(byte b, int off, int len) throws IOException;
IO is blocking read, NIO can be non-blocking, but I found that the file NIO can only be non-blocking, then NIO has no advantage.
I think the need to use NIO is generally other advantages that need to use NIO, such as:
transferTo()/transferFrom()
So, when should I use NIO for file reading and writing? Why is it faster than traditional IO? What is the correct way to use it? Should I use IO or NIO only when reading and writing files?
java nio java-io
edited Nov 15 '18 at 3:14
user207421
261k25208352
asked Nov 15 '18 at 2:27
CitronCitron
122
Private methods are not part of the API. 'Not useful' does not follow from the lack of non-blocking mode. Does the book really say 'faster'? or 'can be faster'? or 'more scaleable'?
– user207421
Nov 15 '18 at 3:22
add a comment |
I am reading the book Thinking in Java, which explains the java.nio.* package and says that NIO is faster than reading and writing files with traditional IO streams. Why?
I have reviewed the following information:
IO stream is byte oriented, traditional IO processing unit is byte, and NIO processing unit is block (byte array), but I think traditional IO can also directly process block (byte array) through BufferedFile*, and traditional IO also has direct Method of processing byte array
private native int readBytes(byte b, int off, int len) throws IOException;
IO is blocking read, NIO can be non-blocking, but I found that the file NIO can only be non-blocking, then NIO has no advantage.
I think the need to use NIO is generally other advantages that need to use NIO, such as:
transferTo()/transferFrom()
So, when should I use NIO for file reading and writing? Why is it faster than traditional IO? What is the correct way to use it? Should I use IO or NIO only when reading and writing files?
java nio java-io
edited Nov 15 '18 at 3:14
user207421
261k25208352
asked Nov 15 '18 at 2:27
CitronCitron
122
I am reading the book Thinking in Java, which explains the java.nio.* package and says that NIO is faster than reading and writing files with traditional IO streams. Why?
I have reviewed the following information:
IO stream is byte oriented, traditional IO processing unit is byte, and NIO processing unit is block (byte array), but I think traditional IO can also directly process block (byte array) through BufferedFile*, and traditional IO also has direct Method of processing byte array
private native int readBytes(byte b, int off, int len) throws IOException;
IO is blocking read, NIO can be non-blocking, but I found that the file NIO can only be non-blocking, then NIO has no advantage.
I think the need to use NIO is generally other advantages that need to use NIO, such as:
transferTo()/transferFrom()
So, when should I use NIO for file reading and writing? Why is it faster than traditional IO? What is the correct way to use it? Should I use IO or NIO only when reading and writing files?
java nio java-io
java nio java-io
edited Nov 15 '18 at 3:14
user207421
261k25208352
asked Nov 15 '18 at 2:27
CitronCitron
122
edited Nov 15 '18 at 3:14
user207421
261k25208352
asked Nov 15 '18 at 2:27
CitronCitron
122
edited Nov 15 '18 at 3:14
user207421
261k25208352
edited Nov 15 '18 at 3:14
user207421
261k25208352
edited Nov 15 '18 at 3:14
user207421
261k25208352
261k25208352
asked Nov 15 '18 at 2:27
CitronCitron
122
asked Nov 15 '18 at 2:27
CitronCitron
122
asked Nov 15 '18 at 2:27
CitronCitron
122
122
Private methods are not part of the API. 'Not useful' does not follow from the lack of non-blocking mode. Does the book really say 'faster'? or 'can be faster'? or 'more scaleable'?
– user207421
Nov 15 '18 at 3:22
add a comment |
Private methods are not part of the API. 'Not useful' does not follow from the lack of non-blocking mode. Does the book really say 'faster'? or 'can be faster'? or 'more scaleable'?
– user207421
Nov 15 '18 at 3:22
Private methods are not part of the API. 'Not useful' does not follow from the lack of non-blocking mode. Does the book really say 'faster'? or 'can be faster'? or 'more scaleable'?
– user207421
Nov 15 '18 at 3:22
Private methods are not part of the API. 'Not useful' does not follow from the lack of non-blocking mode. Does the book really say 'faster'? or 'can be faster'? or 'more scaleable'?
– user207421
Nov 15 '18 at 3:22
add a comment |
1 Answer
1
active
oldest
votes
There are only two cases where a FileChannel is faster than a FileInputStream or FileOutputStream.
The first is when you can use an off-heap ("direct") ByteBuffer to hold data, so that it isn't copied into the Java heap. For example, if you were writing a web-server that delivered static files to a socket, it would be faster to use a FileInputStream and a SocketChannel rather than a FileInputStream and a SocketOutputStream.
These cases are, in my opinion, very few and far between. Normally when you read (or write) a file in Java you will be doing something with the data. In which case, you can't avoid copying the data onto the heap.
The other use for a FileChannel is to create a MappedByteBuffer for random access to the contents of a file. This is significantly faster than using RandomAccessFile because it replaces explicit calls to the OS kernel with memory accesses that leverage the OS's paging mechanism.
If you're just getting started with I/O in Java, I recommend sticking with the classes in java.io unless and until you can explain why switching to java.nio will give you improved performance. It's much easier to use a stream-oriented abstraction than a block-oriented one.
answered Nov 16 '18 at 17:33
guestguest
561
Thank you for your answer, I also very much agree with your point of view. It seems that I should understand the meaning of the wrong book.
– Citron
Nov 18 '18 at 11:09
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53311560%2fwhen-use-filechannel-to-read-write-files%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
There are only two cases where a FileChannel is faster than a FileInputStream or FileOutputStream.
The first is when you can use an off-heap ("direct") ByteBuffer to hold data, so that it isn't copied into the Java heap. For example, if you were writing a web-server that delivered static files to a socket, it would be faster to use a FileInputStream and a SocketChannel rather than a FileInputStream and a SocketOutputStream.
These cases are, in my opinion, very few and far between. Normally when you read (or write) a file in Java you will be doing something with the data. In which case, you can't avoid copying the data onto the heap.
The other use for a FileChannel is to create a MappedByteBuffer for random access to the contents of a file. This is significantly faster than using RandomAccessFile because it replaces explicit calls to the OS kernel with memory accesses that leverage the OS's paging mechanism.
If you're just getting started with I/O in Java, I recommend sticking with the classes in java.io unless and until you can explain why switching to java.nio will give you improved performance. It's much easier to use a stream-oriented abstraction than a block-oriented one.
answered Nov 16 '18 at 17:33
guestguest
561
Thank you for your answer, I also very much agree with your point of view. It seems that I should understand the meaning of the wrong book.
– Citron
Nov 18 '18 at 11:09
add a comment |
There are only two cases where a FileChannel is faster than a FileInputStream or FileOutputStream.
The first is when you can use an off-heap ("direct") ByteBuffer to hold data, so that it isn't copied into the Java heap. For example, if you were writing a web-server that delivered static files to a socket, it would be faster to use a FileInputStream and a SocketChannel rather than a FileInputStream and a SocketOutputStream.
These cases are, in my opinion, very few and far between. Normally when you read (or write) a file in Java you will be doing something with the data. In which case, you can't avoid copying the data onto the heap.
The other use for a FileChannel is to create a MappedByteBuffer for random access to the contents of a file. This is significantly faster than using RandomAccessFile because it replaces explicit calls to the OS kernel with memory accesses that leverage the OS's paging mechanism.
If you're just getting started with I/O in Java, I recommend sticking with the classes in java.io unless and until you can explain why switching to java.nio will give you improved performance. It's much easier to use a stream-oriented abstraction than a block-oriented one.
answered Nov 16 '18 at 17:33
guestguest
561
Thank you for your answer, I also very much agree with your point of view. It seems that I should understand the meaning of the wrong book.
– Citron
Nov 18 '18 at 11:09
add a comment |
There are only two cases where a FileChannel is faster than a FileInputStream or FileOutputStream.
The first is when you can use an off-heap ("direct") ByteBuffer to hold data, so that it isn't copied into the Java heap. For example, if you were writing a web-server that delivered static files to a socket, it would be faster to use a FileInputStream and a SocketChannel rather than a FileInputStream and a SocketOutputStream.
These cases are, in my opinion, very few and far between. Normally when you read (or write) a file in Java you will be doing something with the data. In which case, you can't avoid copying the data onto the heap.
The other use for a FileChannel is to create a MappedByteBuffer for random access to the contents of a file. This is significantly faster than using RandomAccessFile because it replaces explicit calls to the OS kernel with memory accesses that leverage the OS's paging mechanism.
If you're just getting started with I/O in Java, I recommend sticking with the classes in java.io unless and until you can explain why switching to java.nio will give you improved performance. It's much easier to use a stream-oriented abstraction than a block-oriented one.
answered Nov 16 '18 at 17:33
guestguest
561
There are only two cases where a FileChannel is faster than a FileInputStream or FileOutputStream.
The first is when you can use an off-heap ("direct") ByteBuffer to hold data, so that it isn't copied into the Java heap. For example, if you were writing a web-server that delivered static files to a socket, it would be faster to use a FileInputStream and a SocketChannel rather than a FileInputStream and a SocketOutputStream.
These cases are, in my opinion, very few and far between. Normally when you read (or write) a file in Java you will be doing something with the data. In which case, you can't avoid copying the data onto the heap.
The other use for a FileChannel is to create a MappedByteBuffer for random access to the contents of a file. This is significantly faster than using RandomAccessFile because it replaces explicit calls to the OS kernel with memory accesses that leverage the OS's paging mechanism.
If you're just getting started with I/O in Java, I recommend sticking with the classes in java.io unless and until you can explain why switching to java.nio will give you improved performance. It's much easier to use a stream-oriented abstraction than a block-oriented one.
answered Nov 16 '18 at 17:33
guestguest
561
answered Nov 16 '18 at 17:33
guestguest
561
answered Nov 16 '18 at 17:33
guestguest
561
answered Nov 16 '18 at 17:33
guestguest
561
561
Thank you for your answer, I also very much agree with your point of view. It seems that I should understand the meaning of the wrong book.
– Citron
Nov 18 '18 at 11:09
add a comment |
Thank you for your answer, I also very much agree with your point of view. It seems that I should understand the meaning of the wrong book.
– Citron
Nov 18 '18 at 11:09
Thank you for your answer, I also very much agree with your point of view. It seems that I should understand the meaning of the wrong book.
– Citron
Nov 18 '18 at 11:09
Thank you for your answer, I also very much agree with your point of view. It seems that I should understand the meaning of the wrong book.
– Citron
Nov 18 '18 at 11:09
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53311560%2fwhen-use-filechannel-to-read-write-files%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Private methods are not part of the API. 'Not useful' does not follow from the lack of non-blocking mode. Does the book really say 'faster'? or 'can be faster'? or 'more scaleable'?
– user207421
Nov 15 '18 at 3:22