Memory mapped files in java: too many questions?

Question

Files with memory mapping (according to the specification) are largely dependent on the actual OS implementation, and a number of these unknown aspects are already explained in javadoc. However, I have additional questions and do not know where to turn for answers.

Suppose application A maps a file into memory from position=0 to size=10 .

I would suggest that working with the OS requires a continuous chunk of memory? Or is it implementation dependent?

Now suppose we have application B that maps from position=0 to size=11 . Are the first 10 bytes shared or is this a completely different mapping? This relates to the issue of continuous memory.

If we want to use mapped files for IPC, we need to know how data is reflected in other applications, so if B writes to memory, does A do this?

However, since I read the spec, it depends on the OS. This makes it dangerous to use in general-purpose IPCs, since it correctly reduces portability?

Also, suppose the OS supports it, so B writes to memory, A sees a change in what happens if we do this:

 B.write("something"); A.write("stuff"); A.read(); 

What exactly will A read? Or else:

How are file pointers managed?
How does this work with concurrency, is there an application cross-lock?

Answer 1

You can assume that each operating system will perform memory matching in terms of blocks, which usually have a size that is either the power of two of the multiple power of two, and well over 11 bytes.

Thus, regardless of whether you display from 0 to 10 or from 1 to 11, the base system will most likely set the mapping from 0 to lock to logical address X, which will be completely hidden from the Java programmer as a return ByteBuffer It has its own address pointer and capacity, so you can always configure it so that, for example, position 0 gives the address X + 1. But is the base system or Javas MappedByteBuffer important for the translation you need?

Typically, operating systems will use the same block of physical memory to map the same file to the same region, so this is a reasonable way to establish IPC, but as you might have guessed, it really depends on the OS and is not portable. However, it can be useful if you make it optional, and let a user who knows that his system supports it can enable it.

As for your question about two recording files, of course, if two applications write to the same place at the same time, the result is completely unpredictable.

The display of the file area is independent of the lock, but you can use the channel channel API to lock the area in which you are located for exclusive access.