查找Java字节数组的缓存线的起点

对于高性能的BloomFilter，我希望将数据与缓存线对齐。（我知道用C做这样的事情比较容易，但我想用Java。）

我确实有一个解决方案，但我不确定它是否正确，或者是否有更好的方法。我的解决方案尝试使用以下算法查找缓存线的起点：

• 对于每个可能的偏移量o（0..63；我假设缓存线长度为64）
• 启动一个从数据[o]读取并将其写入数据[o+8]的线程
• 在主线程中，将“1”写入数据[o]，并等待它在数据[o+8]中结束（因此等待另一个线程）
• 重复一遍

然后，测量这有多快，基本上是100万个循环的增量（在每个线程中）。我的逻辑是，如果数据在不同的缓存线中，速度会慢一些

这是我的代码：

public static void main(String... args) {
    for(int i=0; i<20; i++) {
        int size = (int) (1000 + Math.random() * 1000);
        byte[] data = new byte[size];
        int cacheLineOffset = getCacheLineOffset(data);
        System.out.println("offset: " + cacheLineOffset);
    }
}

private static int getCacheLineOffset(byte[] data) {
    for (int i = 0; i < 10; i++) {
        int x = tryGetCacheLineOffset(data, i + 3);
        if (x != -1) {
            return x;
        }
    }
    System.out.println("Cache line start not found");
    return 0;
}

private static int tryGetCacheLineOffset(byte[] data, int testCount) {
    // assume synchronization between two threads is faster(?)
    // if each thread works on the same cache line
    int[] counters = new int[64];
    int testOffset = 8;
    for (int test = 0; test < testCount; test++) {
        for (int offset = 0; offset < 64; offset++) {
            final int o = offset;
            final Semaphore sema = new Semaphore(0);
            Thread t = new Thread() {
                public void run() {
                    try {
                        sema.acquire();
                    } catch (InterruptedException e) {
                        throw new RuntimeException(e);
                    }
                    for (int i = 0; i < 1000000; i++) {
                        data[o + testOffset] = data[o];
                    }
                }
            };
            t.start();
            sema.release();
            data[o] = 1;
            int counter = 0;
            byte waitfor = 1;
            for (int i = 0; i < 1000000; i++) {
                byte x = data[o + testOffset];
                if (x == waitfor) {
                    data[o]++;
                    counter++;
                    waitfor++;
                }
            }
            try {
                t.join();
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
            counters[offset] += counter;
        }
    }
    Arrays.fill(data, 0, testOffset + 64, (byte) 0);
    int low = Integer.MAX_VALUE, high = Integer.MIN_VALUE;
    for (int i = 0; i < 64; i++) {
        // average of 3
        int avg3 = (counters[(i - 1 + 64) % 64] + counters[i] + counters[(i + 1) % 64]) / 3;
        low = Math.min(low, avg3);
        high = Math.max(high, avg3);
    }
    if (low * 1.1 > high) {
        // no significant difference between low and high
        return -1;
    }
    int lowCount = 0;
    boolean[] isLow = new boolean[64];
    for (int i = 0; i < 64; i++) {
        if (counters[i] < (low + high) / 2) {
            isLow[i] = true;
            lowCount++;
        }
    }
    if (lowCount != 8) {
        // unclear
        return -1;
    }
    for (int i = 0; i < 64; i++) {
        if (isLow[(i - 1 + 64) % 64] && !isLow[i]) {
            return i;
        }
    }
    return -1;
}

---

因此，Java中的数组似乎与8个字节对齐。

您知道GC可以移动对象。。。因此，完全对齐的阵列以后可能会出现未对齐

我想试试ByteBuffer的

；我猜，一个直接的一个得到了很多对齐（到一个页面边界）

不安全可以为您提供地址，使用JNI，您可以固定数组。
首先，java中的所有内容都是8字节对齐的，而不仅仅是数组。有一个工具，你可以玩。这里的小东西（不相关，但相关）-在
java-9
String
（s）内部存储为
byte[]
，以缩小
LATIN-1
的空间，因为所有东西都是8字节对齐的，所以添加了一个字段
编码器（
byte
）在没有使字符串的任何实例变大的情况下，有一个足够大的间隙来容纳该字节

您认为对齐的对象访问速度更快的想法是正确的。当多个线程试图访问该数据时，这一点会更加明显，也称为
错误共享
（但我敢打赌你知道这一点）。顺便说一句，
Unsafe
中有一些方法会显示对象地址，但由于
GC
可以移动这些地址，因此这对于您的需求来说是无用的

你可能会试图克服这一点。不幸的是，如果你读了这篇博文，你会发现即使是非常有经验的开发人员（我很欣赏）也会在这方面失败。众所周知，VM非常聪明，可以删除您可能认为某个地方需要的检查和代码，特别是当
JIT
C2
生效时

您真正想要的是：

jdk.internal.vm.annotation.Contended

注释。这是保证缓存线对齐的唯一方法。如果你真的想了解所有其他可以做到的“窍门”，那么下面就是你正在寻找的例子
 一些想法：你知道GC可以移动对象。。。因此，完全对齐的阵列以后可能会出现未对齐。我想试试ByteBuffer的
；我猜，一个直接的一个得到了很多对齐（到一个页面边界）。不安全可以给你地址，通过JNI，你可以得到一个固定的数组。@maaartinus你是对的。我将尝试使用ByteBuffer.allocateDirect。根据我的测试，这些看起来总是缓存线对齐的。我会测试它们是否和长数组一样快。@maaartinus（我没有完成测试，但是）如果你把你的评论转换成答案，我会接受。很好！请随意添加更多细节。。。我的回答很简短。你想说，这个数组可以被GC重新设置范围吗？是的，根据规范和文档，它是可能的（“压缩收集器”）。但我不认为非常大的阵列会经常移动。这需要“阻止世界”
jdk.internal.vm.annotation.Contended