blocks|key|309431|text|这可能是因为您的操作系统不允许您尝试创建的线程数量，或者您达到了JVM中的某些限制。特别是如果它是像32k这样的整数，那么这样或那样的限制很可能是罪魁祸首。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|309432|你确定你真的需要32k线程吗？大多数现代语言都有对可重用线程池的某种支持--我敢肯定Java也有一些支持(就像用户Jesper提到的ExecutorService+)。也许您可以从这样的池中请求线程，而不是手动创建新线程。|offset|length|style|CODE|309433|entityMap^0|0|1U|F|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

It's likely that your OS does not allow the number of threads you're trying to create, or you're hitting some limit in the JVM. Especially if it's such a round number as 32k, a limit of one kind or another is a very likely culprit.

Are you sure you truly need 32k threads? Most modern languages have some kind of support for pools of reusable threads - I'm sure Java has something in place too (like <code>ExecutorService</code>, as user Jesper mentioned). Perhaps you could request threads from such a pool, instead of manually creating new ones.

blocks|key|92449|text|如果您的作业由于节点上的OutOfMemmory而失败，您可以查看最大映射和缩减程序的数量，以及每个映射和缩减程序的JVM选项。mapred.child.java.opts+(默认值为200Xmx)通常需要根据您的数据节点特定的硬件而增加。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|92450|This+link可能会有帮助...请查收|offset|length|92451|entityMap|0|LINK|mutability|MUTABLE|url|http://www.mastertheboss.com/jboss-monitoring/how-to-solve-javalangoutofmemoryerror-unable-to-create-new-native-thread^0|0|0|9|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

If your Job is failing because of OutOfMemmory on nodes you can tweek your number of max maps and reducers and the JVM opts for each. mapred.child.java.opts (the default is 200Xmx) usually has to be increased based on your data nodes specific hardware.

<a href="http://www.mastertheboss.com/jboss-monitoring/how-to-solve-javalangoutofmemoryerror-unable-to-create-new-native-thread" rel="nofollow">This link</a> might be helpful... pls check

blocks|key|309535|text|这不是内存问题，尽管异常名称高度暗示了这一点，但这是操作系统资源问题。您正在耗尽本地线程，即操作系统允许您的JVM使用的线程数。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|309536|这是一个不常见的问题，因为您很少需要这么多。在线程应该完成但没有完成的地方，你有很多无条件的线程衍生吗？|309537|如果可能的话，您可以考虑重写为在Executor控制下使用Callable/Runnables。有许多具有各种行为的标准执行器，您的代码可以很容易地控制它们。|309538|(线程数量有限的原因有很多，但不同的操作系统会有所不同)|309539|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|$]]

This is not a memory problem even though the exception name highly suggests so, but an operating system resource problem. You are running out of native threads, i.e. how many threads the operating system will allow your JVM to use. 

This is an uncommon problem, because you rarely need that many. Do you have a lot of unconditional thread spawning where the threads should but doesn't finish? 

You might consider rewriting into using Callable/Runnables under the control of an Executor if at all possible. There are plenty of standard executors with various behavior which your code can easily control.

(There are many reasons why the number of threads is limited, but they vary from operating system to operating system)

blocks|key|92543|text|你的JBoss配置有一些问题，/opt/jrockit-jdk1.6/bin/java+-Xms512m+-Xmx512m+Xms和Xmx将你的JBoss内存使用限制在配置值上，所以从8+8Gb开始，服务器只使用512M+%2B一些额外的空间用于自己的目的，增加这个数字，记住为操作系统和其他运行在那里的东西留出一些空闲空间，也许你可以让它运行，尽管有一些令人讨厌的代码。如果可以的话，修复代码也会很好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|92544|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|$]]

your JBoss configuration has some issues,
/opt/jrockit-jdk1.6/bin/java -Xms512m -Xmx512m
Xms and Xmx are limiting your JBoss memory usage, to the configured value, so from the 8Gb you have the server is only ussing 512M + some extra for his own purpose, increase that number, remember to leave some free for the OS and other stuff running there and may be you get it running despite de unsavoury code.
Fixing the code would be nice too, if you can.

blocks|key|92549|text|我也遇到了同样的问题，结果发现是对java+API的不当使用。我在一个批处理方法中初始化一个构建器，这个方法应该不会被多次初始化。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|92550|基本上，我是这样做的：|92551|for+(batch+in+batches)+{
++++process_batch(batch)
}

def+process_batch(batch)+{
++++var+client+=+TransportClient.builder().build()
++++client.processList(batch)
}|code-block|syntax|javascript|92552|当我应该这样做的时候：|92553|for+(batch+in+batches)+{
++++var+client+=+TransportClient.builder().build()
++++process_batch(batch,+client)
}

def+process_batch(batch,+client)+{
++++client.processList(batch)
}|92554|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

I had this same issue and it turned out to be an improper usage of an java API. I was initializing a builder in a batch processing method that was that not supposed to be initiallized more than once.

Basically I was doing something like:

<pre><code>for (batch in batches) {
 process_batch(batch)
}

def process_batch(batch) {
 var client = TransportClient.builder().build()
 client.processList(batch)
}
</code></pre>

when I should have done this:

<pre><code>for (batch in batches) {
 var client = TransportClient.builder().build()
 process_batch(batch, client)
}

def process_batch(batch, client) {
 client.processList(batch)
}
</code></pre>

blocks|key|92571|text|我遇到了同样的问题，因为在bash中使用top时，虚拟进程没有显示出来。这阻止了JVM产生更多的线程。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|92572|对我来说，当使用jps列出所有java进程(只需在shell中执行jps+)并使用kill+-9+pid+bash命令分别杀死每个ghost进程时，这个问题就解决了。|offset|length|style|CODE|92573|这在某些情况下可能会有所帮助。|92574|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.oracle.com/javase/7/docs/technotes/tools/share/jps.html^0|0|X|3|15|B|8|3|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@$D|T|E|U|F|G]|$D|V|E|W|F|G]]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|H|3|I|5|6|7|10|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

I had the same problem due to ghost processes that didn't show up when using top in bash. This prevented the JVM to spawn more threads.

For me, it resolved when listing all java processes with <a href="http://docs.oracle.com/javase/7/docs/technotes/tools/share/jps.html" rel="nofollow noreferrer">jps</a> (just execute <code>jps</code> in your shell) and killed them separately using the <code>kill -9 pid</code> bash command for each ghost process.

This might help in some scenarios.

blocks|key|92595|text|要找出哪些进程正在创建线程，请尝试：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|92596|ps+huH|code-block|syntax|javascript|92597|我通常将输出重定向到一个文件，并脱机分析该文件(每个进程的线程数是否与预期一致)|92598|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

To find which processes are creating threads try:

<pre><code>ps huH
</code></pre>

I normally redirect output to a file and analysis the file offline (is thread count for each process is as expected or not)

blocks|key|92623|text|如果通过systemd启动jvm，那么在某些linux操作系统中，每个进程可能会有maxTasks限制(任务实际上意味着线程)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|92624|您可以通过运行“服务状态”来检查这一点，并检查是否有maxTasks限制。如果有，您可以通过编辑/etc/systemd/system.conf，添加一个配置来删除它:+DefaultTasksMax=infinity|92625|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|$]]

If jvm is started via systemd, there might be a maxTasks per process limit (tasks actually mean threads) in some linux OS.

You can check this by running "service status" and check if there is a maxTasks limit. If there is, you can remove it by editing /etc/systemd/system.conf, adding a config: DefaultTasksMax=infinity

blocks|key|92659|text|我在centOS/Red+Hat机器上也遇到了同样的问题。您正在达到线程限制、用户、进程或总体限制|type|unstyled|depth|inlineStyleRanges|entityRanges|data|92660|在我的例子中，每个用户可以拥有的线程数是有限制的。可以用来检查，这一行表示最大用户进程数|92661|ulimit+-a|offset|length|style|CODE|92662|您可以使用以下命令查看有多少线程正在运行|92663|$+ps+-elfT+%7C+wc+-l|92664|要获取您的进程正在运行的线程数(您可以使用top或ps+aux获取您的进程pid+)：|92665|$+ps+-p+<PROCESS_PID>+-lfT+%7C+wc+-l|92666|proc/sys/kernel/+threads+-max文件提供了系统范围内的线程数量限制。root用户可以更改该值|92667|要更改限制(本例中为4096个线程)，请执行以下操作：|92668|$+ulimit+-u+4096|92669|您可以在此处找到有关Red+/centOs+http://www.mastertheboss.com/jboss-server/jboss-monitoring/how-to-solve-javalangoutofmemoryerror-unable-to-create-new-native-thread的更多信息|92670|entityMap|0|LINK|mutability|MUTABLE|url|http://www.mastertheboss.com/jboss-server/jboss-monitoring/how-to-solve-javalangoutofmemoryerror-unable-to-create-new-native-thread^0|0|0|0|9|0|0|0|I|0|0|0|Y|0|0|0|0|G|0|M|3N|0|0^^$0|@$1|2|3|4|5|6|7|17|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|18|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|19|8|@$F|1A|G|1B|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|1C|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1D|8|@$F|1E|G|1F|H|I]]|9|@]|A|$]]|$1|N|3|O|5|6|7|1G|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1H|8|@$F|1I|G|1J|H|I]]|9|@]|A|$]]|$1|R|3|S|5|6|7|1K|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1L|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1M|8|@$F|1N|G|1O|H|I]]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1P|8|@]|9|@$F|1Q|G|1R|1|1S]]|A|$]]|$1|Z|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]]|10|$11|$5|12|13|14|A|$15|16]]]]

I had the same problem in a centOS/Red Hat machine. You are reaching the threads limit, for the user, process, or an overall limit
In my case there was a limit on the number of threads a user can have. Which can be checked with, the line saying max user processes
<code>ulimit -a </code>
You can see how many threads are running using this command
<code>$ ps -elfT | wc -l</code>
To get how many threads your process is running (you can get your process pid using top or ps aux):
<code>$ ps -p &lt;PROCESS_PID&gt; -lfT | wc -l</code>
The /proc/sys/kernel/threads-max file provides a system-wide limit for the number of threads. The root user can change that value
To change the limits (in this case to 4096 threads):
<code>$ ulimit -u 4096 </code>
You can find more info here for Red Hat/centOs <a href="http://www.mastertheboss.com/jboss-server/jboss-monitoring/how-to-solve-javalangoutofmemoryerror-unable-to-create-new-native-thread" rel="nofollow noreferrer">http://www.mastertheboss.com/jboss-server/jboss-monitoring/how-to-solve-javalangoutofmemoryerror-unable-to-create-new-native-thread</a>

We are getting <code>"java.lang.OutOfMemoryError : unable to create new native Thread</code>" on 8GB RAM VM after 32k threads (ps -eLF| grep -c java)

However, <code>"top" and "free -m" shows 50% free memory available</code>. JDk is 64 bit and tried with both HotSpot and JRockit.Server has Linux 2.6.18

We also tried <code>OS stack size (ulimit -s)</code> tweaking and max process(ulimit -u) limits, limit.conf increase but all in vain.

Also we tried almost all possible of heap size combinations, keeping it low, high etc.

The script we use to run application is 

<pre><code>/opt/jrockit-jdk1.6/bin/java -Xms512m -Xmx512m -Xss128k -jar JavaNatSimulator.jar /opt/tools/jnatclients/natSimulator.properties
</code></pre>

Thanks for the reply.

We have tried editing /etc/security/limits.conf and ulimit but still that same

<pre><code>[root@jboss02 ~]# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 72192
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 65535
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 72192
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
</code></pre>

"java.lang.OutOfMemoryError : unable to create new native Thread"

服务器

虚拟机

Java

在32k线程之后，我们在8 8GB内存虚拟机上获得"java.lang.OutOfMemoryError : unable to create new native Thread“(ps -eLF| grep -c java)然而，"top" and "free -m" shows 50% free memory av...

问"java.lang.OutOfMemoryError :无法创建新的本机线程“
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问"java.lang.OutOfMemoryError :无法创建新的本机线程“EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问"java.lang.OutOfMemoryError :无法创建新的本机线程“
EN