blocks|key|4185341|text|如果您使用的是JDK1.5%2B，ConcurrentHashMap是一个很好的选择。它是有效的。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4185342|请参阅：What's+the+difference+between+ConcurrentHashMap+and+Collections.synchronizedMap(Map)?|4185343|此外，我认为put()可能会导致在映射中分配新的内存和更多的时间，但get()不会。所以在put()中会阻塞更多的线程。|style|CODE|4185344|另外，优化您的键类的hashCode()方法。这一点很重要，因为在您的情况下，哈希码计算是密集的操作。如果键对象是不可变的，则只计算一次散列代码，并将其保存为成员，然后直接在hashCode()中返回。|4185345|entityMap|0|LINK|mutability|MUTABLE|url|http://concurrenthashmap/|1|https://stackoverflow.com/questions/510632/whats-the-difference-between-concurrenthashmap-and-collections-synchronizedmapm^0|F|H|0|0|4|2D|1|0|6|5|Y|5|19|5|0|A|A|2F|A|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]]|C|$]]|$1|D|3|E|5|6|7|Z|8|@]|9|@$A|10|B|11|1|12]]|C|$]]|$1|F|3|G|5|6|7|13|8|@$A|14|B|15|H|I]|$A|16|B|17|H|I]|$A|18|B|19|H|I]]|9|@]|C|$]]|$1|J|3|K|5|6|7|1A|8|@$A|1B|B|1C|H|I]|$A|1D|B|1E|H|I]]|9|@]|C|$]]|$1|L|3|-4|5|6|7|1F|8|@]|9|@]|C|$]]]|M|$N|$5|O|P|Q|C|$R|S]]|T|$5|O|P|Q|C|$R|U]]]]

If you are using JDK1.5+, <a href="http://ConcurrentHashMap" rel="nofollow noreferrer">ConcurrentHashMap</a> is a good choice. It's effective. 

See: <a href="https://stackoverflow.com/questions/510632/whats-the-difference-between-concurrenthashmap-and-collections-synchronizedmapm">What's the difference between ConcurrentHashMap and Collections.synchronizedMap(Map)?</a>

Also, I think <code>put()</code> may lead new memory allocate in map and more time consuming, but <code>get()</code> not. So more threads will be blocked in <code>put()</code>.

Also, Optimize the <code>hashCode()</code> method of your key class. It's important, as hash code calculation is intensive operation in your case. If the key object is immutable, calculate the hash code just once and save it as a member and return it directly in <code>hashCode()</code>.

blocks|key|4185404|text|OutOfMemoryError可能是由存储的大量对象引起的，而不是由大量线程引起的，并且OOME不是性能问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4185405|顺便说一句，您可以使用ConcurrentHashMap进行快速并发读取和写入，而不是使用一个全局锁。|4185406|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

OutOfMemoryError can be caused by large number of objects stored, not by large number of threads, and OOME is not a performance problem.

BTW, you can use ConcurrentHashMap for fast concurrent reads and writes, and do not use one global lock.

blocks|key|4185439|text|你试过ConcurrentHashMap吗？在正确的编码环境下，您不需要任何同步。内部有多个条带化锁来减少争用，还有许多很好的复合原子操作，比如putIfAbsent，可以让您完全删除外部锁。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4185440|至于内存，我怀疑您确实在JVM中存储了大量内存。使用诸如visualvm之类的监视工具来检查它，或者向JVM分配中添加更多内存。考虑一下像EHCache这样的缓存，它会自动溢出到磁盘，并在内部使用ConcurrentHashMap，并且具有各种漂亮的绑定选项|4185441|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Have you tried a ConcurrentHashMap? Under the right coding circumstances you won't need any synchronization. There are multiple striped locks internally to reduce contention, and many nice compound atomic operations like putIfAbsent that may allow you to drop external locks entirely.

As for memory, I suspect you really are storing a lot in the JVM. Use a monitor tool like visualvm to check it out, or add more memory to the JVM allocation. Consider a cache like EHCache that will automatically overflow to disk and internally uses a ConcurrentHashMap, and has all kinds of nice bounding options

blocks|key|2401481|text|听起来你的问题是内存，而不是性能。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2401482|尝试使用相同的哈希码将最近访问次数最少的键和值写入文件，并将其从内存中清除。|2401483|如果文件存储的哈希码被寻址，则将最近最少使用的哈希码的关键字和销售量写入文件并从内存中清除，然后将所需的存储读取文件读到内存中。|2401484|考虑多个级别的哈希图(每个哈希图都有不同的键)来提高性能。|2401485|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Sounds like your problem is memory, not performance.

Try writing least recently accessed keys and values with same hashcode to a file
and clearing them from memory.

If a file stored hashcode is addressed, write next least recently used hash code's keys and sales to a file and clear from memory,
then read desired stored read file to memory.

Consider multiple levels of hashmaps (each with different keys) for improving performance of this.

blocks|key|2401498|text|如果您希望保留当前的实现，则可能还需要考虑通过更改传递给Java的-Xms和-Xmx参数来更改分配给应用程序的内存量。还存在许多其他参数。无论使用哪种实现，都可能有必要这样做。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2401499|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you would like to keep your current implementation, you might also want to consider changing the amount of memory allocated to the application by changing the -Xms and -Xmx parameters passed to Java. Many other parameters exist as well. It may be necessary to do this regardless of the implementation used.

blocks|key|4185571|text|我怀疑你是因为线程的数量而耗尽了PermGen内存。你的OutOfMemoryError异常应该告诉你它是堆还是PermGen。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4185572|Java语言中的每个线程使用大约256-512KB的堆栈，这些堆栈是从PermGen分配的。因此，20,000个线程*256K字节=5+64，远远超出了默认的PermGen大小(通常为64-256M字节)。|4185573|您应该将线程数限制在几百个以内。看看Java5/6的并发包，特别是ThreadPoolExecutor。|4185574|entityMap|0|LINK|mutability|MUTABLE|url|http://download.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html^0|S|G|0|0|X|I|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|U|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|V|8|@]|D|@$9|W|A|X|1|Y]]|E|$]]|$1|J|3|-4|5|6|7|Z|8|@]|D|@]|E|$]]]|K|$L|$5|M|N|O|E|$P|Q]]]]

I suspect you're running out of PermGen memory due to the number of threads. Your <code>OutOfMemoryError</code> exception should tell you if it's heap or PermGen.

Each thread in Java uses about 256-512 Kbytes for its stack, which is allocated from PermGen. So 20,000 threads * 256 Kbytes = 5 Gbytes which way beyond the default PermGen size (usually 64-256 Mbytes).

You should limit the number of threads to less than a few hundred. Take a look Java 5/6's concurrent package, in particular <a href="http://download.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html" rel="nofollow">ThreadPoolExecutor</a>.

blocks|key|492371|text|你可以使用ConcurrentHashMap代替它，它比常规的map有更多的优势。我不确定您是否在使用Java5，因为它只在版本5中可用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|492372|另外，我要说的是，再考虑一下你的逻辑，你是否真的需要读操作的同步。如果它不是，你可以删除它，你将节省一些性能。|492373|如果您确实感觉到内存不足问题，您可以使用上面提到的更多vm内存选项来运行jvm。试试看。:)|492374|让你的键的hashcode方法更有效。您可以依靠Pojomatic等其他apis来完成这些工作。|offset|length|492375|entityMap|0|LINK|mutability|MUTABLE|url|http://code.google.com/p/pojomatic/^0|0|0|0|O|9|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@$H|V|I|W|1|X]]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

You can use ConcurrentHashMap instead of that and it has more advantages over regular map.
I am not sure whether you are using Java5, since it is available from version 5 only.

Also, I would say that, think once again on your logic whether you really require synchronization on read operations. If it's not, you can remove that and you will save some performance.

If you are really feel a low memory issue, you can run the jvm with more vm memory options said above. Give it a try. :)

Have your hashcode method for the keys efficient. You can depend on other apis such as <a href="http://code.google.com/p/pojomatic/" rel="nofollow">Pojomatic</a> to do that stuff.

blocks|key|2111722|text|至于你问题的最后部分：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2111723|有什么建议可以让我的hashmap写得更好吗？这也可能是我在内存中存储如此多数据的方法的限制？|2111724|我使用一个工具来查看应用程序在做什么。它可以进行堆和线程转储。它还有一个监控器，用于显示cpu、加载的类、线程、堆和perm+gen。它被称为Java，是JDK1.6的一部分，可执行文件位于jdk的VisualVM文件夹中。我将使用它来跟踪我们代码中的一些线程问题。|2111725|哈哈，詹姆斯|2111726|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

As far as the last part of your question: 

Any recommendations on how i can make my hashmap more performant for writes? This may also be a limitation with my approach of storing so much data in memory?

I use a tool to take a look at what the application is doing. It can do heap and thread dumps. It also has a montior that displays the cpu, classes loaded, threads, heap, and perm gen. It's called Java VisualVM and it's part of jdk 1.6 The exe is in the bin folder of the jdk. I'm going to use it for tracking down some threading issues in our code.

HTH,
James

i have a hashmap in my application. The map is in a singleton and access to update or read it is protected using synchronized methods. 

My problem occurs when testing with large numbers(20000+) of concurrent threads. When threads are writing to the map using put() im getting OutOfMemory exception.

Read operations are fine (i can simulate 1000000+ threads) without any issue.

Any recommendations on how i can make my hashmap more performant for writes? This may also be a limitation with my approach of storing so much data in memory?

hashmap put performance issue

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我的应用程序中有一个哈希图。映射是单例的，对其进行更新或读取的访问是使用同步方法来保护的。我的问题发生在使用大量并发线程(20000+)进行测试时。当线程使用put()写入映射时，im会得到OutOfMemory异常。读操作很好(我可以模拟1000000+线程)，没有任何问题。有什么建议可以让我的hashmap写得更好...

问hashmap put性能问题
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问hashmap put性能问题EN