java concurrent programming --AtomicInteger

1. The issues raised

Class member variables properties and look under the AtomicInteger:

// setup to use Unsafe.compareAndSwapInt for updates
    private static final Unsafe unsafe = Unsafe.getUnsafe();
    private static final long valueOffset;

    static {
        try {
            valueOffset = unsafe.objectFieldOffset
                (AtomicInteger.class.getDeclaredField("value"));
        } catch (Exception ex) { throw new Error(ex); }
    }

    private volatile int value;

can be seen:

 1.AtomicInteger class uses Unsafe, direct memory operations to ensure atomicity.

 2. There is a long type of valueOffset. When the class is loaded and initialized value.

 3. have a member variable of type int with volatile modified value.

See this, which is obviously a value AtomicInteger packaged value, that value we get. But what is it valueOffset value represents? And this is how unsafe operation?

 

2.valueOffset

  See their assignments initialization method, it is a native of unsafe method:

public native long objectFieldOffset(Field var1);

objectFieldOffset method returns the address in memory member property with respect to the object memory address offset (from Baidu) 

   Then for each object, the offset is fixed, as a class variable.

 Then the memory address + offset object can know the member variable value specific address in memory, and this time we can manipulate it, and this time java from "safe" to be "unsafe" the.

3. With regard to unsafe

  It is unsafe for direct operation of a memory-based, we look at the AtomicInteger by the method of usage.

  a, look at how the increment decrement Typical non-atomic operation is done AtomicInteger.

    

/**
     * Atomically increments by one the current value.
     *
     * @return the previous value
     */
    public final int getAndIncrement() {
        return unsafe.getAndAddInt(this, valueOffset, 1);
    }

    /**
     * Atomically decrements by one the current value.
     *
     * @return the previous value
     */
    public final int getAndDecrement() {
        return unsafe.getAndAddInt(this, valueOffset, -1);
    }

Look at the results:

 

 The return value is the value of the old, do not use the wrong

This is what we saw of unsafe method:

public final int getAndAddInt(Object var1, long var2, int var4) {
        int var5;
        do {
            var5 = this.getIntVolatile(var1, var2);
        } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));

        return var5;
    }

Unsafe.getObjectVolatile()：

Given the acquired object to the value of the variable, the use of volatile semantic semantic load, will load from main memory the actual value acquired this time is not used in the CPU cache, always to ensure that it is effective to obtain the value

compareAndSwapInt(var1, var2, var5, var5 + var4)：

 Find out the location in memory Object var1 p, var2 and offset bytes, provided p+var2that at int value y,
if y ==var5, assignment is executed y = var5+var4, returns true
if y != var5not performed assignment, returnsfalse

 

That unsafe.getAndAddInt (Object var1, long var2, int var4) we read the code:

 1. Take a member variable to a value at offset var1 var2 the formation, after the value is read as a desired value.

2. At the time of assignment, the memory fetch start to compare and expected values, if they are equal, then calculates assignment, returns a successful end.

3. Otherwise, the first step in the cycle.

CAS is actually realized in unsafe in.

Then look at other methods of AtomicInteger

 b.

/**
     * Gets the current value.
     *
     * @return the current value
     */
    public final int get() {
        return value;
    }

    /**
     * Sets to the given value.
     *
     * @param newValue the new value
     */
    public final void set(int newValue) {
        value = newValue;
    }

 The easiest method get set because a member variable is volatile modifications, both to ensure the visibility of memory.

c.

The remaining methods will not list them, but the basic principles are all unsafe.compareAndSwapInt (), summed up the old saying is the use of CAS to ensure the atomicity.