创建（和释放）数百万个小对象的最佳实践是什么？
我正在使用Java编写一个象棋程序，搜索算法为每个可能的移动生成单个“Move”对象，而标准搜索可以轻松生成每秒超过一百万个移动对象。 JVM GC已能够处理开发系统上的负载，但我有兴趣探索替代方法，以便：
绝大多数对象的寿命非常短，但是生成的移动中约有1％会被持久化并返回作为持久化值，因此任何缓存技术都必须提供排除特定对象不被重用的能力。
我不希望完全详细的示例代码，但我希望获得进一步阅读/研究建议或具有类似性质的开源示例。
使用详细垃圾回收运行应用程序:
java -verbose:gc
它会告诉你何时进行收集。有两种扫描类型，快速扫描和完整扫描。
[GC 325407K->83000K(776768K), 0.2300771 secs]
[GC 325816K->83372K(776768K), 0.2454258 secs]
[Full GC 267628K->83769K(776768K), 1.8479984 secs]
箭头在前后大小之间。
只要进行的是垃圾回收（GC）而不是完整的GC，您就安全了。常规GC是“年轻代”中的复制收集器，因此不再引用的对象只是被遗忘，这正是您想要的。
阅读Java SE 6 HotSpot虚拟机垃圾收集调整可能会有所帮助。
嗯，这里有几个问题！
1 - 如何管理短寿命的对象？
正如之前所述，JVM可以完美地处理大量的短生命周期对象，因为它遵循弱代假说。
请注意，我们所说的是已经进入主内存（堆）的对象。这并不总是这种情况。你创建的很多对象甚至不会离开CPU寄存器。例如，考虑以下for循环：
for(int i=0, i<max, i++) {
// stuff that implies i
}
不需要考虑循环展开（JVM对您的代码进行的优化）。如果max等于Integer.MAX_VALUE，则您的循环可能需要一些时间才能执行。但是i变量永远不会逃出循环块。因此，JVM将在CPU寄存器中放置该变量，并定期递增它，但永远不会将其发送回主内存。
因此，如果创建的数百万个对象仅在本地使用，则并不是什么大问题。它们将在存储在Eden之前被释放，因此GC甚至不会注意到它们。
2-减少GC开销是否有用？
像往常一样，这要看情况。
首先，您应该启用GC日志记录以清楚地了解发生了什么。您可以使用-Xloggc:gc.log -XX:+PrintGCDetails启用它。
如果您的应用程序在GC周期中花费了大量时间，那么请调整GC，否则可能不值得。
例如，如果您每100ms进行一次Young GC，而它需要10ms，那么您就花费了10％的时间在GC上，并且您每秒有10次GC（这非常巨大）。在这种情况下，我不会花费任何时间进行GC调整，因为这10个GC / s仍然存在。
3-一些经验
我在一个应用程序上遇到了类似的问题，该应用程序创建了大量给定类的对象。在GC日志中，我注意到应用程序的创建率约为3 GB / s，这太多了（来吧...每秒3千兆字节的数据？！）。
问题：由于创建了太多的对象而导致太多频繁的GC。
在我的情况下，我附加了一个内存分析器并注意到一个类代表了所有对象的巨大百分比。我追踪了实例化，以发现该类基本上是一个包裹在对象中的布尔值对。在这种情况下，有两个解决方案：
重新设计算法，使我不返回布尔值对，而是有两种方法分别返回每个布尔值
缓存对象，知道只有4个不同的实例
我选择了第二个，因为它对应用程序的影响最小，并且很容易引入。我花了几分钟时间放置了一个具有非线程安全缓存的工厂（我不需要线程安全，因为最终只会有4个不同的实例）。
分配率下降到1 GB / s，年轻GC的频率也相应降低（减少了3倍）。
希望这有所帮助！
ByteBuffers，这是很重要的，你需要几百行代码来分配/重用+ getter / setter。getter看起来类似于long getQuantity(int tupleIndex){return buffer.getLong(tupleInex+QUANTITY_OFFSSET);}
如果你只分配一次，也就是说，分配一个巨大的块，然后自己管理对象，那么这将几乎完全解决GC问题。ByteBuffer中只有索引（即int），而不是引用，必须传递它们。您可能还需要自己进行内存对齐。C和void*，但通过一些包装，它是可承受的。性能的缺点可能是边界检查，如果编译器无法消除它。一个主要的优势是局部性，如果您像向量一样处理元组，则对象头的缺乏也会减少内存占用。final字段，分配成本可能会更高，因为它们在一些平台上需要内存屏障（即ARM / Power），在x86上是免费的。测量前/后等等
我遇到了类似的问题。首先，尝试减小小对象的大小。我们引入了一些默认字段值，在每个对象实例中引用它们。
例如，MouseEvent 引用 Point 类。我们缓存 Points 并引用它们，而不是创建新的实例。对于空字符串也是同样的处理。
另一个问题是多个布尔变量，这些变量被替换为一个整数，并且对于每个布尔变量，我们只使用整数的一个字节。
我曾经用一些XML处理代码来处理这种情况。我发现自己创建了数百万个XML标记对象，它们非常小（通常只是一个字符串），并且非常短暂（XPath检查失败意味着不匹配，所以需要丢弃）。
我进行了一些严格的测试，并得出结论：使用已丢弃标记的列表而不是创建新标记，我只能实现大约7%的速度提升。然而，一旦实施，我发现如果空闲队列变得太大，就需要添加一种机制来修剪它 - 这完全抵消了我的优化，所以我将其切换为选项。
总之 - 可能不值得，但我很高兴看到你在考虑它，这表明你关心。
我不是GC的忠实拥护者，所以我总是尝试找到绕过它的方法。在这种情况下，我建议使用对象池模式：
这个想法是通过将对象存储在堆栈中来避免创建新对象，以便稍后可以重用它们。
Class MyPool
{
LinkedList<Objects> stack;
Object getObject(); // takes from stack, if it's empty creates new one
Object returnObject(); // adds to stack
}