False Sharing && Java 7

简介:

In my previous post on False Sharing I suggested it can be avoided by padding the cache line with unused longfields.  It seems Java 7 got clever and eliminated or re-ordered the unused fields, thus re-introducing false sharing.  I’ve experimented with a number of techniques on different platforms and found the following code to be the most reliable.


import java.util.concurrent.atomic.AtomicLong;

public final class FalseSharing
    implements Runnable
{
    public final static int NUM_THREADS = 4; // change
    public final static long ITERATIONS = 500L * 1000L * 1000L;
    private final int arrayIndex;

    private static PaddedAtomicLong[] longs = new PaddedAtomicLong[NUM_THREADS];
    static
    {
        for (int i = 0; i < longs.length; i++)
        {
            longs[i] = new PaddedAtomicLong();
        }
    }

    public FalseSharing(final int arrayIndex)
    {
        this.arrayIndex = arrayIndex;
    }

    public static void main(final String[] args) throws Exception
    {
        final long start = System.nanoTime();
        runTest();
        System.out.println("duration = " + (System.nanoTime() - start));
    }

    private static void runTest() throws InterruptedException
    {
        Thread[] threads = new Thread[NUM_THREADS];

        for (int i = 0; i < threads.length; i++)
        {
            threads[i] = new Thread(new FalseSharing(i));
        }

        for (Thread t : threads)
        {
            t.start();
        }

        for (Thread t : threads)
        {
            t.join();
        }
    }

    public void run()
    {
        long i = ITERATIONS + 1;
        while (0 != --i)
        {
            longs[arrayIndex].set(i);
        }
    }

    public static long sumPaddingToPreventOptimisation(final int index)
    {
        PaddedAtomicLong v = longs[index];
        return v.p1 + v.p2 + v.p3 + v.p4 + v.p5 + v.p6;
    }

    public static class PaddedAtomicLong extends AtomicLong
    {
        public volatile long p1, p2, p3, p4, p5, p6 = 7L;
    }
}

With this code I get similar performance results to those stated in the previous False Sharing article.  The padding inPaddedAtomicLong above can be commented out to see the false sharing effect.

I think we should all lobby the powers that be inside Oracle to have intrinsics added to the language so we can have cache line aligned and padded atomic classes.  This and some other low-level changes would help make Java a real concurrent programming language.  We keep hearing them say multi-core is coming.   I say it is here and Java needs to catch up.


文章转自 并发编程网-ifeve.com

相关文章
|
6月前
|
缓存 Java API
为什么Java中“1000==1000”为false,而”100==100“为true
为什么Java中“1000==1000”为false,而”100==100“为true
44 0
|
6月前
|
Java
java判断时间是否为节假日(或指定的日期),是的话返回true,否返回false
java判断时间是否为节假日(或指定的日期),是的话返回true,否返回false
115 0
|
6月前
|
Java
java判断时间是否为节假日(或指定的日期),是的话返回true,否返回false
java判断时间是否为节假日(或指定的日期),是的话返回true,否返回false
190 0
|
6月前
|
Java
Java【问题 05】yml配置文件boolean一直为false问题分析解决
Java【问题 05】yml配置文件boolean一直为false问题分析解决
178 0
Java用户线程和守护线程,线程默认Daemon值是false吗?
Java用户线程和守护线程,线程默认Daemon值是false吗?
Java用户线程和守护线程,线程默认Daemon值是false吗?
|
缓存 Java API
为什么 Java 中“1000==1000”为false,而”100==100“为true?
为什么 Java 中“1000==1000”为false,而”100==100“为true?
|
9天前
|
安全 Java 测试技术
Java并行流陷阱:为什么指定线程池可能是个坏主意
本文探讨了Java并行流的使用陷阱,尤其是指定线程池的问题。文章分析了并行流的设计思想,指出了指定线程池的弊端,并提供了使用CompletableFuture等替代方案。同时,介绍了Parallel Collector库在处理阻塞任务时的优势和特点。