做企业规划的网站,网站建设心得总结,微信网站开发 全屏,网站建设工作安排方案在上一篇文章中#xff0c;我详细介绍了代码对主内存的访问方式的含义。 从那时起#xff0c;我对使用Java可以做什么以实现更可预测的内存布局有很多疑问。 有些模式可以使用数组支持的结构来应用#xff0c;我将在另一篇文章中讨论。 这篇文章将探讨如何模拟Java中非常缺少… 在上一篇文章中我详细介绍了代码对主内存的访问方式的含义。 从那时起我对使用Java可以做什么以实现更可预测的内存布局有很多疑问。 有些模式可以使用数组支持的结构来应用我将在另一篇文章中讨论。 这篇文章将探讨如何模拟Java中非常缺少的功能-与C提供的功能类似的结构数组。 结构在堆栈和堆上都非常有用。 据我所知不可能在Java堆栈上模拟此功能。 无法在堆栈上执行此操作真是令人遗憾因为它极大地限制了某些并行算法的性能但这又是另一回事。 在Java中所有用户定义的类型都必须存在于堆中。 在一般情况下Java堆由垃圾收集器管理但是Java进程中的堆更大。 通过引入直接ByteBuffer 可以分配内存垃圾回收器不会跟踪该内存因为本机代码可将其用于任务例如避免为IO向内核复制数据或从内核复制数据。 因此一种管理结构的方法是在ByteBuffer中伪造它们这是一种合理的方法。 这可以允许紧凑的数据表示但是具有性能和大小限制。 例如不可能有一个大于2GB的ByteBuffer并且所有访问都经过边界检查这会影响性能。 存在使用Unsafe的替代方法它不仅速度更快而且不受ByteBuffer的大小限制。 我要详细介绍的方法不是传统的Java。 如果您的问题空间正在处理大数据或极高的性能那么就会有好处。 如果您的数据集很小并且性能不是问题那么请立即逃避以避免陷入本机内存管理的黑手党。 我将详细介绍的方法的好处是 显着改善的性能 更紧凑的数据表示 能够处理非常大的数据集同时避免了令人讨厌的GC暂停[1] 各种选择都有其后果。 通过采用下面详述的方法您将自己负责一些内存管理。 弄错了会导致内存泄漏或者更糟的是您可能使JVM崩溃 谨慎行事... 合适的例子– 贸易数据 财务应用程序面临的一个共同挑战是捕获和处理大量的订单和交易数据。 对于该示例我将创建一个很大的内存贸易数据表可以对它运行分析查询。 该表将使用两种对比方法构建。 首先我将采用传统的Java方法创建大型数组并引用单个Trade对象。 其次我保持用法代码相同但是用可通过Flyweight模式操作的堆外结构数组替换大数组和Trade对象。 如果对于传统的Java方法我使用其他一些数据结构例如Map或Tree则内存占用量将更大而性能会更低。 传统的Java方法 public class TestJavaMemoryLayout {private static final int NUM_RECORDS 50 * 1000 * 1000;private static JavaMemoryTrade[] trades;public static void main(final String[] args){for (int i 0; i 5; i){System.gc();perfRun(i);}}private static void perfRun(final int runNum){long start System.currentTimeMillis();init();System.out.format(Memory %,d total, %,d free\n,Runtime.getRuntime().totalMemory(),Runtime.getRuntime().freeMemory());long buyCost 0;long sellCost 0;for (int i 0; i NUM_RECORDS; i){final JavaMemoryTrade trade get(i);if (trade.getSide() B){buyCost (trade.getPrice() * trade.getQuantity());}else{sellCost (trade.getPrice() * trade.getQuantity());}}long duration System.currentTimeMillis() - start;System.out.println(runNum - duration duration ms);System.out.println(buyCost buyCost sellCost sellCost);}private static JavaMemoryTrade get(final int index){return trades[index];}public static void init(){trades new JavaMemoryTrade[NUM_RECORDS];final byte[] londonStockExchange {X, L, O, N};final int venueCode pack(londonStockExchange);final byte[] billiton {B, H, P};final int instrumentCode pack( billiton);for (int i 0; i NUM_RECORDS; i){JavaMemoryTrade trade new JavaMemoryTrade();trades[i] trade;trade.setTradeId(i);trade.setClientId(1);trade.setVenueCode(venueCode);trade.setInstrumentCode(instrumentCode);trade.setPrice(i);trade.setQuantity(i);trade.setSide((i 1) 0 ? B : S);}}private static int pack(final byte[] value){int result 0;switch (value.length){case 4:result (value[3]);case 3:result | ((int)value[2] 8);case 2:result | ((int)value[1] 16);case 1:result | ((int)value[0] 24);break;default:throw new IllegalArgumentException(Invalid array size);}return result;}private static class JavaMemoryTrade{private long tradeId;private long clientId;private int venueCode;private int instrumentCode;private long price;private long quantity;private char side;public long getTradeId(){return tradeId;}public void setTradeId(final long tradeId){this.tradeId tradeId;}public long getClientId(){return clientId;}public void setClientId(final long clientId){this.clientId clientId;}public int getVenueCode(){return venueCode;}public void setVenueCode(final int venueCode){this.venueCode venueCode;}public int getInstrumentCode(){return instrumentCode;}public void setInstrumentCode(final int instrumentCode){this.instrumentCode instrumentCode;}public long getPrice(){return price;}public void setPrice(final long price){this.price price;}public long getQuantity(){return quantity;}public void setQuantity(final long quantity){this.quantity quantity;}public char getSide(){return side;}public void setSide(final char side){this.side side;}} } 紧凑型堆外结构 import sun.misc.Unsafe;import java.lang.reflect.Field;public class TestDirectMemoryLayout {private static final Unsafe unsafe;static{try{Field field Unsafe.class.getDeclaredField(theUnsafe);field.setAccessible(true);unsafe (Unsafe)field.get(null);}catch (Exception e){throw new RuntimeException(e);}}private static final int NUM_RECORDS 50 * 1000 * 1000;private static long address;private static final DirectMemoryTrade flyweight new DirectMemoryTrade();public static void main(final String[] args){for (int i 0; i 5; i){System.gc();perfRun(i);}}private static void perfRun(final int runNum){long start System.currentTimeMillis();init();System.out.format(Memory %,d total, %,d free\n,Runtime.getRuntime().totalMemory(),Runtime.getRuntime().freeMemory());long buyCost 0;long sellCost 0;for (int i 0; i NUM_RECORDS; i){final DirectMemoryTrade trade get(i);if (trade.getSide() B){buyCost (trade.getPrice() * trade.getQuantity());}else{sellCost (trade.getPrice() * trade.getQuantity());}}long duration System.currentTimeMillis() - start;System.out.println(runNum - duration duration ms);System.out.println(buyCost buyCost sellCost sellCost);destroy();}private static DirectMemoryTrade get(final int index){final long offset address (index * DirectMemoryTrade.getObjectSize());flyweight.setObjectOffset(offset);return flyweight;}public static void init(){final long requiredHeap NUM_RECORDS * DirectMemoryTrade.getObjectSize();address unsafe.allocateMemory(requiredHeap);final byte[] londonStockExchange {X, L, O, N};final int venueCode pack(londonStockExchange);final byte[] billiton {B, H, P};final int instrumentCode pack( billiton);for (int i 0; i NUM_RECORDS; i){DirectMemoryTrade trade get(i);trade.setTradeId(i);trade.setClientId(1);trade.setVenueCode(venueCode);trade.setInstrumentCode(instrumentCode);trade.setPrice(i);trade.setQuantity(i);trade.setSide((i 1) 0 ? B : S);}}private static void destroy(){unsafe.freeMemory(address);}private static int pack(final byte[] value){int result 0;switch (value.length){case 4:result | (value[3]);case 3:result | ((int)value[2] 8);case 2:result | ((int)value[1] 16);case 1:result | ((int)value[0] 24);break;default:throw new IllegalArgumentException(Invalid array size);}return result;}private static class DirectMemoryTrade{private static long offset 0;private static final long tradeIdOffset offset 0;private static final long clientIdOffset offset 8;private static final long venueCodeOffset offset 8;private static final long instrumentCodeOffset offset 4;private static final long priceOffset offset 4;private static final long quantityOffset offset 8;private static final long sideOffset offset 8;private static final long objectSize offset 2;private long objectOffset;public static long getObjectSize(){return objectSize;}void setObjectOffset(final long objectOffset){this.objectOffset objectOffset;}public long getTradeId(){return unsafe.getLong(objectOffset tradeIdOffset);}public void setTradeId(final long tradeId){unsafe.putLong(objectOffset tradeIdOffset, tradeId);}public long getClientId(){return unsafe.getLong(objectOffset clientIdOffset);}public void setClientId(final long clientId){unsafe.putLong(objectOffset clientIdOffset, clientId);}public int getVenueCode(){return unsafe.getInt(objectOffset venueCodeOffset);}public void setVenueCode(final int venueCode){unsafe.putInt(objectOffset venueCodeOffset, venueCode);}public int getInstrumentCode(){return unsafe.getInt(objectOffset instrumentCodeOffset);}public void setInstrumentCode(final int instrumentCode){unsafe.putInt(objectOffset instrumentCodeOffset, instrumentCode);}public long getPrice(){return unsafe.getLong(objectOffset priceOffset);}public void setPrice(final long price){unsafe.putLong(objectOffset priceOffset, price);}public long getQuantity(){return unsafe.getLong(objectOffset quantityOffset);}public void setQuantity(final long quantity){unsafe.putLong(objectOffset quantityOffset, quantity);}public char getSide(){return unsafe.getChar(objectOffset sideOffset);}public void setSide(final char side){unsafe.putChar(objectOffset sideOffset, side);}} } 结果 Intel i7-860 2.8GHz, 8GB RAM DDR3 1333MHz, Windows 7 64-bit, Java 1.7.0_07java -server -Xms4g -Xmx4g TestJavaMemoryLayout Memory 4,116,054,016 total, 1,108,901,104 free 0 - duration 19334ms Memory 4,116,054,016 total, 1,109,964,752 free 1 - duration 14295ms Memory 4,116,054,016 total, 1,108,455,504 free 2 - duration 14272ms Memory 3,817,799,680 total, 815,308,600 free 3 - duration 28358ms Memory 3,817,799,680 total, 810,552,816 free 4 - duration 32487msjava -server TestDirectMemoryLayout Memory 128,647,168 total, 126,391,384 free 0 - duration 983ms Memory 128,647,168 total, 126,992,160 free 1 - duration 958ms Memory 128,647,168 total, 127,663,408 free 2 - duration 873ms Memory 128,647,168 total, 127,663,408 free 3 - duration 886ms Memory 128,647,168 total, 127,663,408 free 4 - duration 884msIntel i7-2760QM 2.40GHz, 8GB RAM DDR3 1600MHz, Linux 3.4.11 kernel 64-bit, Java 1.7.0_07java -server -Xms4g -Xmx4g TestJavaMemoryLayout Memory 4,116,054,016 total, 1,108,912,960 free 0 - duration 12262ms Memory 4,116,054,016 total, 1,109,962,832 free 1 - duration 9822ms Memory 4,116,054,016 total, 1,108,458,720 free 2 - duration 10239ms Memory 3,817,799,680 total, 815,307,640 free 3 - duration 21558ms Memory 3,817,799,680 total, 810,551,856 free 4 - duration 23074msjava -server TestDirectMemoryLayout Memory 123,994,112 total, 121,818,528 free 0 - duration 634ms Memory 123,994,112 total, 122,455,944 free 1 - duration 619ms Memory 123,994,112 total, 123,103,320 free 2 - duration 546ms Memory 123,994,112 total, 123,103,320 free 3 - duration 547ms Memory 123,994,112 total, 123,103,320 free 4 - duration 534ms 分析 让我们将结果与上面承诺的3个好处进行比较。 1.显着改善性能 这里的证据很明确。 使用堆外结构方法要快一个数量级以上。 最极端的情况是在Sandy Bridge处理器上运行第五次 完成任务所需的时间相差43.2 倍 。 这也很好地说明了Sandy Bridge在可预测的数据访问模式方面的表现。 性能不仅明显更好而且更加一致。 随着堆变得碎片化因此访问模式变得更加随机性能会下降这在以后使用标准Java方法运行时可以看到。 2.更紧凑的数据表示 对于我们的堆外表示每个对象需要42个字节。 如示例所示要存储其中的5000万个字节我们需要2100,000,000字节。 JVM堆所需的内存为 所需内存总内存–可用内存–基本JVM需求 2,883,248,712 3,817,799,680 – 810,551,856 – 123,999,112 这意味着JVM需要多40的内存来表示相同的数据。 产生这种开销的原因是对Java对象的引用数组以及对象标头。 在上一篇文章中我讨论了Java中的对象布局。 当处理非常大的数据集时此开销可能成为重要的限制因素。 3.能够处理非常大的数据集同时避免令人讨厌的GC暂停 上面的示例代码在每次运行之前强制执行GC循环并且在某些情况下可以提高结果的一致性。 随时删除对System.gc的调用并亲自观察其中的含义。 如果运行添加以下命令行参数的测试则垃圾收集器将详细输出发生的情况。 -XX PrintGC -XX PrintGCDetails -XX PrintGCDateStamps -XX PrintTenuringDistribution -XX PrintHeapAtGC -XX PrintGCApplicationConcurrentTime -XX PrintGCApplicationStoppedTime -XX PrintSafepointStatistics 通过分析输出我可以看到该应用程序总共进行了29个GC循环。 通过从输出中提取指示应用程序线程何时停止的行下面列出了暂停时间。 With System.gc() before each runTotal time for which application threads were stopped: 0.0085280 seconds Total time for which application threads were stopped: 0.7280530 seconds Total time for which application threads were stopped: 8.1703460 seconds Total time for which application threads were stopped: 5.6112210 seconds Total time for which application threads were stopped: 1.2531370 seconds Total time for which application threads were stopped: 7.6392250 seconds Total time for which application threads were stopped: 5.7847050 seconds Total time for which application threads were stopped: 1.3070470 seconds Total time for which application threads were stopped: 8.2520880 seconds Total time for which application threads were stopped: 6.0949910 seconds Total time for which application threads were stopped: 1.3988480 seconds Total time for which application threads were stopped: 8.1793240 seconds Total time for which application threads were stopped: 6.4138720 seconds Total time for which application threads were stopped: 4.4991670 seconds Total time for which application threads were stopped: 4.5612290 seconds Total time for which application threads were stopped: 0.3598490 seconds Total time for which application threads were stopped: 0.7111000 seconds Total time for which application threads were stopped: 1.4426750 seconds Total time for which application threads were stopped: 1.5931500 seconds Total time for which application threads were stopped: 10.9484920 seconds Total time for which application threads were stopped: 7.0707230 secondsWithout System.gc() before each runTest run times 0 - duration 12120ms 1 - duration 9439ms 2 - duration 9844ms 3 - duration 20933ms 4 - duration 23041msTotal time for which application threads were stopped: 0.0170860 seconds Total time for which application threads were stopped: 0.7915350 seconds Total time for which application threads were stopped: 10.7153320 seconds Total time for which application threads were stopped: 5.6234650 seconds Total time for which application threads were stopped: 1.2689950 seconds Total time for which application threads were stopped: 7.6238170 seconds Total time for which application threads were stopped: 6.0114540 seconds Total time for which application threads were stopped: 1.2990070 seconds Total time for which application threads were stopped: 7.9918480 seconds Total time for which application threads were stopped: 5.9997920 seconds Total time for which application threads were stopped: 1.3430040 seconds Total time for which application threads were stopped: 8.0759940 seconds Total time for which application threads were stopped: 6.3980610 seconds Total time for which application threads were stopped: 4.5572100 seconds Total time for which application threads were stopped: 4.6193830 seconds Total time for which application threads were stopped: 0.3877930 seconds Total time for which application threads were stopped: 0.7429270 seconds Total time for which application threads were stopped: 1.5248070 seconds Total time for which application threads were stopped: 1.5312130 seconds Total time for which application threads were stopped: 10.9120250 seconds Total time for which application threads were stopped: 7.3528590 seconds 从输出中可以看出垃圾回收器花费了大量时间。 当线程停止时您的应用程序无响应。 这些测试已使用默认GC设置完成。 可以调整GC以获得更好的结果但这可能是一项非常熟练的工作。 我知道即使在高吞吐量条件下即使不在高吞吐量条件下也不施加较长的暂停时间这可以很好地应对JVM。 在对该应用程序进行性能分析时我可以看到大部分时间都花在分配对象并将它们提升到老一代因为它们不适合年轻一代。 可以从计时中除去初始化成本但这是不现实的。 如果采用传统的Java方法则需要先建立状态然后才能进行查询。 应用程序的最终用户必须等待状态建立和查询执行。 这个测试确实非常简单。 想象一下使用100 GB规模的相似数据集。 注意当垃圾收集器压缩区域时可以将彼此相邻的对象移开很远。 这可能会导致TLB和其他缓存未命中。 关于序列化的旁注 以这种方式使用堆外结构的一个巨大好处是如何通过简单的内存副本将它们很容易地序列化到网络或存储中就像我在上一篇文章中所展示的那样。 这样我们可以完全绕过中间缓冲区和对象分配。 结论 如果您愿意对大型数据集进行一些C风格的编程则可以通过脱离堆控制Java中的内存布局。 如果这样做那么在性能紧凑性和避免GC问题方面的好处就非常重要。 但是这种方法不应该用于所有应用程序。 仅对于非常大的数据集或吞吐量和/或延迟的极端性能才注意到它的优势。 我希望Java社区可以共同认识到支持在堆和堆栈上的结构的重要性。 John Rose在这方面做了出色的工作 定义了如何将元组添加到JVM。 他今年在JVM语言峰会上发表的有关Arrays 2.0的演讲确实值得关注。 约翰在演讲中讨论了结构数组的选择和数组结构。 如果有John提出的元组可用则此处描述的测试可以具有可比的性能并且是更令人愉快的编程风格。 整个结构数组可以在一个动作中分配从而绕开了跨代的单个对象的副本并且可以紧凑的连续方式进行存储。 这将消除此类问题中的重大GC问题。 最近我比较了Java和.Net之间的标准数据结构。 在某些情况下当.Net使用本机结构支持时对于诸如地图和字典之类的东西我发现.Net的性能优势是6-10倍。 让我们尽快将其纳入Java 从结果也很明显如果我们要使用Java对大数据进行实时分析那么我们的标准垃圾收集器就需要显着改善并支持真正的并发操作。 [1] –据我所知唯一处理非常大堆的JVM是Azul Zing 祝您编程愉快别忘了分享 参考来自Java的JCG合作伙伴 Martin Thompson在Mechanical Sympathy博客上的紧凑型堆外结构/堆栈在Java中 。 翻译自: https://www.javacodegeeks.com/2012/10/compact-off-heap-structurestuples-in.html