Probe into the source of Netty5 (i.)----BYTEBUF

Netty of the various profiles, the overall structure is not introduced, if you feel that really need to give me a message I add.

Here again to promote a self-made netty+spring integration scheme, optimize the Netty configuration start, and provide the base server configuration + very few code implementation scenarios.

http://download.csdn.net/detail/jackieliyido/9497093

Return to business: Let's start from the Netty core class Bytebuf. First look at the abstract class definition, the following method we specifically see the core implementation abstractbytebuf

First look at Bytebuf source code.

Tell the compiler to ignore the classmaybeinterface warning first.

Then see that the Bytebuf class itself implements a Netty reference counter, as well as a compareble interface. Why write here, because the first reaction when looking at a class name is that this class inherits from Bytebuffer.

Then look at the notes, notes are important, as Netty beginners is the most important guide line.

* 
It is recommended to use helper methods to create a new buffer, and it is not recommended to use the constructor that implements the class itself.

Next paragraph:
* 

This section of the comparison of water, in fact, the BYTEBUF is to follow the 0 as the first digit count way. The first glimpse of zero-based indexing did not respond, and then a look at the beginning of the 0 count. Well, the author is very responsible, at the same time learned a loaded word zero-based indexing ...
At the same time I do not miss the above sentence, buffer.capacity (), this method is to obtain the buffer capacity. Buffer.getbyte (i), gets the byte data at the specified location

The play begins to come and look at the following paragraph:
* 
Sequential Access Index, BYTEBUF provides two pointer scalars to support read and write operations. Well, this is a bit like the question that the interviewer asked before, how to implement a queue with a loop array.
Look at the first paragraph of the picture, is discarded bytes, this and our computer disk operation, the deletion of the file is just the file's description pointer from the current position to remove (well, I do not know what the pointer is even a pointer), the area is set as a new spatial identity, well, that is probably the meaning.
In the first paragraph, there is a readerindex, that is, between 0 and Readindex, the bytes are discarded (read out). Readerindex to Writerindex for readable content, the area between writeable to capacity is a writable area.
What's easy to misunderstand here is what is write,read. Reading and writing here does not mean that we write the data out, read the data come in two simultaneous actions, but refers to a single business behavior such as reading the data in the actual occurrence of the underlying action. It's a little bit around, it seems a little superfluous.
A few diagrams should be shown (this section refers to the "Netty Authoritative guide"):
When initializing the BYTEBUF:
*      +---------------------------------------------------------+ *      |                    Writable bytes                       | *      |                                                         | *      +---------------------------------------------------------+ *      |                                                         | *      0 =readerindex =writerindex                           capacity

Write Bytebuf for n-word:
*      +--------------------------------------+------------------+ *      |                Readable bytes        |  Writable bytes  |<pre name= "code" class= "java" > * | | |                  
* +--------------------------------------+------------------+ * | | * 0 =readerindex N=writerindex capacity
After reading M (m<n) Bytes:
*      +-------------------+------------------+------------------+ *      | discardable bytes |  Readable bytes  |  Writable bytes  | * | | |                  | *      +-------------------+------------------+------------------+ *      |                   |                  |                  | *      0            m=readerindex      n=writerindex          capacity

Call the Bytebuf after the discardreadbytes operation:
*      +-------------------+-------------------------------------+ *      | readable bytes    |           Writable bytes            | * | |                                     | *      +-------------------+-------------------------------------+ *      |                   |                                     | *      0=readerindex      n-m=writerindex                    capacity

After calling the Clear method:
*      +---------------------------------------------------------+ *      |                    Writable bytes                       | *      |                                                         | *      +---------------------------------------------------------+ *      |                                                         | *      0 =readerindex =writerindex                           capacity
After careful reading of the above figures, you can know how Readerindex and writerindex work.

Going back to the comment, we skimmed through the code about two pointers, and came to the following:
* 
This is a description of search/searching, for simple list search, we recommend using Bytebuf.indexof (int FromIndex,int Toindex,byte value), Bytesbefore (int index,int length,byte value) and Bytesbefore (byte value) for retrieval, a coarse look at the description of these methods, all refers to the readable area (that is, the portion between Readerindex and Writerindex) to retrieve a specific value, return to the index value of the first value found, otherwise return-1.

About resetting and tagging:
* 
The Rederindex and Writerindex can be thought of as two marker and can be reset like InputStream, except that InputStream has readlimit parameters.
Add the Readlimit role in Inputstream.mark (int readlimit): In InputStream, Mark's role is when you finish a data point, When you continue reading, you can return to mark's location by calling the Reset method. However, this mark needs to have a limit that, when you are reading the Readlimit data length, will retain Mark, beyond which Mark is no longer retained

About derived buffers:
* 
Calling duplicate (), slice (), slice (int index, int length) Creates a view of an existing buffer. The derived buffers have separate readerindex, Writerindex, and label indexes that share internal data. If you need a fresh copy of an existing buffer, you can get it using copy ().
It is necessary to note that the Duplicate,slice method holds a separate read-write index, but shares the content pointer reference. That is, modifying the contents of the copy will affect the contents of the original.

The last paragraph, about converting to a class that already exists in the JDK
 * 
Array: If a bytebuf is an array type, you can use the array () method to determine whether the method for the arrays is: HasArray ()
NIO Buffer: You can convert Bytebuf to Java.nio.ByteBuffer by using the Niobuffer () method. The method to determine if it can be converted is: Niobuffercount (). Niobuffercount () returns the number of NiO buffer, or 1 if not.
The string:tostring (Charset) converts the bytes of the readable area into a string with the specified encoding, and the conversion does not modify Readerindex and Writerindex. ToString () Prints memory address and does not convert to string
IO stream: See Bytebufinputstream and Bytebufoutputstream for future analysis

First write this first, then we mainly analyze Abstractbytebuf, Heapbytebuf, Directbytebuf and several other core implementations.


Probe into the source of Netty5 (i.)----BYTEBUF