我想在hadoop框架中计算一个多路连接。当每个关系的记录从一个阈值开始变大，超过这个阈值，我就面临两个记忆问题，
1） 错误：超出gc开销限制，
2） 错误：java堆空间。
对于链联接和星形联接，阈值是1.000.000/关系。
在连接计算中，我使用一些哈希表，即。

Hashtable< V, LinkedList< K>> ht = new Hashtable< V, LinkedList< K>>( someSize, o.75F);

当我对输入记录进行散列时，这些错误才会出现，而且只有在此时。在散列过程中，我有很多for循环，它们产生了很多临时对象。因为这个原因，我遇到了问题。所以，我通过设置k=stringbuilder解决了这个问题，这是最后一个类。换句话说，我减少了临时对象的数量，因为只有少数对象的值、内容发生了变化，但它们本身却没有变化。
现在，我正在处理这个问题。通过在$hadoop\u home/hadoop/conf/hadoop-env.sh文件中设置适当的变量，我增加了集群中每个节点的堆空间。问题仍然存在。我使用visualvm对堆进行了非常基本的监视。我只监视主节点，尤其是jobtracker和本地tasktracker守护进程。在此监视期间，我没有注意到任何堆溢出。而且永磁发电机的空间没有溢出。
所以现在，在宣言中，

Hashtable< V, LinkedList< K>> ht = new Hashtable< V, LinkedList< K>>( someSize, o.75F);

我正在考虑设置v=somefinalclass。这个somefinal类将帮助我保持对象的数量低，从而内存使用。当然，默认情况下，somefinalclass对象将具有与其内容无关的相同哈希代码。所以我将不能使用这个somefinalclass作为上面哈希表中的键。为了解决这个问题，我考虑用一个类似的string.hashcode（）方法重写默认的hashcode（）方法。此方法将基于somefinalclass对象的内容生成哈希代码。
您对上述问题及解决办法有何看法？你会怎么做？
我应该同时监视datanode守护进程吗？以上两个错误都是tasktracker错误、datanode错误还是两者都是？
最后，上述解决方案能否解决任意数量记录/关系的问题？或者不久或晚些时候我又会有同样的问题？