Netty in Action (14) fifth chapter Part III BYTEBUFHOLDER,BYTEBUF allocation, count reference

5.4 Interface Bytebufholder

We often store some of the normal data in the bytebuf, we sometimes need to add a number of different property values, an HTTP response body is a good example, in addition to the bytes transmitted over the main content, there are status codes, cookies and other information

Netty provides bytebufholder to handle these common user cases, Bytebufholder also provides netty some other advanced features, such as a cache pool, which can be a direct "loan" fetch in Bytebuf, and "lend" if needed Bytebuf can also be automatically added to the pool.

Bytebufholder provides a series of methods to get the underlying data and reference count, and table 5.6 shows you some common methods

If you want to implement a message object that can store its payload in Bytebuf, using Bytebufholder is a good choice.

5.5 Bytebuf allocation

In this section, we will discuss several ways to manage BYTEBUF instances

5.5.1 On-demand:interface Bytebufallocator

To reduce the allocation of memory and the consumption of memory, Netty uses interface Bytebufallocator to implement the management pool, which can allocate any instance of Bytebuf that we define, and the use of the management pool is the specific needs of the application. It does not change the default API for Bytebuf

Table 5.7 shows you some of the actions that Bytebufallocator provides

You can get a bytebufallocator reference from a channel or from Channelhandlercontext, and the following code listing shows how these methods

Netty provides two specific implementations of the Bytebufallocator interface, Pooledbytebufallocator and Unpooledbytebufallocator, The former pooled storage bytebuf to improve performance and reduce the appearance of memory fragmentation, this method uses the more famous efficient "Jemalloc" to allocate management memory, this technology has been used in the current more popular operating systems, or no pooled storage bytebuf instances, Instead, each call returns a new instance

Netty defaults to using Pooledbytebufallocator, but this can be easily changed by modifying the channelconfig or by specifying different types when you bootstrap in the project, with detailed information referring to the contents of chapter eighth

5.5.2 unpooled Buffers

In some cases, you may not have a bytebufallocator reference, in which case Netty provides a special class called unppoled, which provides a static tool method to create a non-pooled bytebuf instance, Table 5.8 shows the more important methods in unpooled

Unpooled classes can also make bytebuf not available in non-network projects, enabling these projects to benefit from high-performance, scalable BUFFERAPI, and using some of the other components that will not involve Netty

5.5.3 Class Bytebufutil

Bytebufutil provides a number of static tool methods to control Bytebuf, because Bytebufutil APIs are generic, pool-independent, and can be used by other classes in addition to the class implementations that allocate memory

The most important method in these static methods is probably the Hexdump method, which prints the contents of the bytebuf contained in a hexadecimal character, which is very important in many cases, when locating problems and output journaling, the hexadecimal representation is more friendly than getting the value of byte directly , and that is, the hexadecimal version of the data can be easily reversed to the real data format

Another useful method is the Equals method, which confirms that the two Bytebuf instances are equal, and if you implement your own Bytebuf class, you may find bytebufutil other useful methods

5.6 Reference Counting

Reference counting is a technique for optimizing memory usage, and if the resources held by an object are no longer referenced by any object, this part of the resource is freed, and Netty introduces a technology for reference counting in its fourth version of Bytebuf and Bytebufholder. Both BYTEBUF and Bytebufholder have implemented referencecounted technology.

The theory of reference counting is not very complicated, in most cases it will track the number of references to a specific object, and an instance that implements the Referencecounted interface typically starts counting to 1 for a surviving object, as long as the number of references to that object is not 0. The resources held by this object will certainly not be released, and when the number of references to a surviving object drops to 0, the instance is freed, noting that the explicit definition of "release" is not very clear, but at least if an object has been "freed" then the object will no longer be used

Reference counting is critical to the implementation of the pool technology, such as Pooledbytebufallocator, which reduces memory allocation losses and shows this example in the following two code listings

If you try to get a reference count of a specific object, but the object has been released, it throws a Illegalreferencecountexception exception

Note that an object can define its own release count contract in its own unique method, and we can assume that its implementation method, release, simply sets its reference count to 0, regardless of its actual current reference count, which makes the surviving object immediately invalid and becomes illegal.

Who's RESPONSIBLE for RELEASE? In general, the last time you get the object is responsible for releasing it, and in the sixth chapter we will explain its associated channelhandler and Channelpipeline

5.7 Summary

This chapter is dedicated to learning Netty data containers, containers are based on bytebuf, we began to explain why BYTEBUF performance is higher than the JDK, we also highlighted a new API, and explained each of their use of the scene

The following is what we have just mentioned:

1) Read and write two different indexes control this our operation on the data

2) different memory usage methods---backing Arrays and direct buffers

3) You can use Compositebytebuf to gather multiple bytebuf

4) Data access methods: Searching,slicing and copying

5) Read,write,get and set API for these methods

6) Bytebufallocator Pool and reference count

In the next chapter, the component we focus on is Channelhandler, which is the key to our data processing logic, because the Channelhandler class uses BYTEBUF, and you will start to see that some of the core components of Netty will be combined to be used

Netty in Action (14) fifth chapter Part III BYTEBUFHOLDER,BYTEBUF allocation, count reference