blocks|key|274298|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|274299|为什么创建线程的代价很高？|blockquote|274300|274301|274302|因为它>>is<<昂贵。|274303|Java线程的创建代价很高，因为涉及到大量的工作：|274304|274305|必须为线程堆栈分配和初始化很大的内存块。需要使用主机OS.|unordered-list-item|274306|Descriptors创建/注册本机线程时，需要进行|274307|系统调用。需要创建、初始化并添加到|274308|内部数据结构。|274309|274310|线程只要还活着就会占用资源，这也是代价高昂的；例如，线程堆栈、可从堆栈到达的任何对象、JVM线程描述符、OS本机线程描述符。|274311|所有这些东西的成本都是特定于平台的，但它们在我遇到的任何Java平台上都不便宜。|274312|274313|谷歌搜索我发现了一个old+benchmark，它报告在运行2002年的Linux的双处理器Xeon上的Sun+Java+1.4.1上的线程创建速度为每秒大约4000次。一个更现代的平台会给出更好的数字。我不能评论这个方法..。但至少它为创建线程的代价提供了一个大概的估计。|offset|length|274314|Peter+Lawrey的基准测试表明，现在线程创建的绝对速度要快得多，但尚不清楚这在多大程度上是由于Java和/或操作系统的改进……或者更高的处理器速度。但他的数字仍然表明，与每次创建/启动一个新线程相比，如果使用线程池，150%2B的性能会提高一倍。(他指出这一切都是相对的……)|274315|274316|上面假设使用本机线程，而不是绿色线程，但是出于性能原因，现代JVM都使用本机线程。创建绿色线程的成本可能更低，但您可以在其他领域为其买单。|274317|更新:+OpenJDK+Loom+project的目标是为标准Java线程提供一个轻量级的替代方案。他们提出了虚拟线程，它是本机线程和绿色线程的混合体。简单地说，当需要并行执行时，虚拟线程更像是一个绿色线程实现，它使用底层的本机线程。|274318|截至目前(2021年1月)，Project+Loom的工作仍处于原型阶段，(AFAIK)没有针对发布的Java版本。|274319|274320|我做了一些深入研究，以了解Java线程的堆栈是如何真正分配的。在Linux6的情况下，线程堆栈是通过调用创建本机线程的pthread_create来分配的。(+JVM不会向pthread_create传递预先分配的堆栈。)|style|CODE|274321|然后，在pthread_create中通过调用mmap来分配堆栈，如下所示：|274322|mmap(0,+attr.__stacksize,+
+++++PROT_READ%7CPROT_WRITE%7CPROT_EXEC,+
+++++MAP_PRIVATE%7CMAP_ANONYMOUS,+-1,+0)|code-block|syntax|javascript|274323|根据man+mmap的说法，MAP_ANONYMOUS标志会导致内存初始化为零。|274324|因此，即使新的Java线程栈可能不是必须的(根据JVM规范)，但在实践中(至少对于Linux上的OpenJDK+6)，它们是零的。|274325|entityMap|0|LINK|mutability|MUTABLE|url|http://www.mail-archive.com/java-linux@java.blackdown.org/msg15146.html|1|https://wiki.openjdk.java.net/display/loom/Main^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|A|D|0|0|0|0|0|C|C|1|0|0|0|1N|E|2E|E|0|4|E|N|4|0|0|2|8|E|D|0|0^^$0|@$1|2|3|-4|4|5|6|22|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|23|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|24|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|25|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|26|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|27|7|@]|8|@]|9|$]]|$1|J|3|-4|4|5|6|28|7|@]|8|@]|9|$]]|$1|K|3|L|4|M|6|29|7|@]|8|@]|9|$]]|$1|N|3|O|4|M|6|2A|7|@]|8|@]|9|$]]|$1|P|3|Q|4|M|6|2B|7|@]|8|@]|9|$]]|$1|R|3|S|4|M|6|2C|7|@]|8|@]|9|$]]|$1|T|3|-4|4|5|6|2D|7|@]|8|@]|9|$]]|$1|U|3|V|4|5|6|2E|7|@]|8|@]|9|$]]|$1|W|3|X|4|5|6|2F|7|@]|8|@]|9|$]]|$1|Y|3|-4|4|5|6|2G|7|@]|8|@]|9|$]]|$1|Z|3|10|4|5|6|2H|7|@]|8|@$11|2I|12|2J|1|2K]]|9|$]]|$1|13|3|14|4|5|6|2L|7|@]|8|@]|9|$]]|$1|15|3|-4|4|5|6|2M|7|@]|8|@]|9|$]]|$1|16|3|17|4|5|6|2N|7|@]|8|@]|9|$]]|$1|18|3|19|4|5|6|2O|7|@]|8|@$11|2P|12|2Q|1|2R]]|9|$]]|$1|1A|3|1B|4|5|6|2S|7|@]|8|@]|9|$]]|$1|1C|3|-4|4|5|6|2T|7|@]|8|@]|9|$]]|$1|1D|3|1E|4|5|6|2U|7|@$11|2V|12|2W|1F|1G]|$11|2X|12|2Y|1F|1G]]|8|@]|9|$]]|$1|1H|3|1I|4|5|6|2Z|7|@$11|30|12|31|1F|1G]|$11|32|12|33|1F|1G]]|8|@]|9|$]]|$1|1J|3|1K|4|1L|6|34|7|@]|8|@]|9|$1M|1N]]|$1|1O|3|1P|4|5|6|35|7|@$11|36|12|37|1F|1G]|$11|38|12|39|1F|1G]]|8|@]|9|$]]|$1|1Q|3|1R|4|5|6|3A|7|@]|8|@]|9|$]]|$1|1S|3|-4|4|5|6|3B|7|@]|8|@]|9|$]]]|1T|$1U|$4|1V|1W|1X|9|$1Y|1Z]]|20|$4|1V|1W|1X|9|$1Y|21]]]]

<blockquote>
Why is creating a Thread said to be expensive?
</blockquote>
Because it &gt;&gt;is&lt;&lt; expensive.
Java thread creation is expensive because there is a fair bit of work involved:
<ul>
<li>A large block of memory has to be allocated and initialized for the thread stack.</li>
<li>System calls need to be made to create / register the native thread with the host OS.</li>
<li>Descriptors need to be created, initialized and added to JVM-internal data structures.</li>
</ul>
It is also expensive in the sense that the thread ties down resources as long as it is alive; e.g. the thread stack, any objects reachable from the stack, the JVM thread descriptors, the OS native thread descriptors.
The costs of all of these things are platform specific, but they are not cheap on any Java platform I've ever come across.
<hr />
A Google search found me an <a href="http://www.mail-archive.com/java-linux@java.blackdown.org/msg15146.html" rel="noreferrer">old benchmark</a> that reports a thread creation rate of ~4000 per second on a Sun Java 1.4.1 on a 2002 vintage dual processor Xeon running 2002 vintage Linux. A more modern platform will give better numbers ... and I can't comment on the methodology ... but at least it gives a ballpark for how expensive thread creation is likely to be.
Peter Lawrey's benchmarking indicates that thread creation is significantly faster these days in absolute terms, but it is unclear how much of this is due improvements in Java and/or the OS ... or higher processor speeds. But his numbers still indicate a 150+ fold improvement if you use a thread pool versus creating/starting a new thread each time. (And he makes the point that this is all relative ...)
<hr />
The above assumes native threads rather than green threads, but modern JVMs all use native threads for performance reasons. Green threads are possibly cheaper to create, but you pay for it in other areas.
Update: The OpenJDK <a href="https://wiki.openjdk.java.net/display/loom/Main" rel="noreferrer">Loom project</a> aims to provide a light-weight alternative to standard Java threads, among other things. The are proposing virtual threads which are a hybrid of native threads and green threads. In simple terms, a virtual thread is rather like a green thread implementation that uses native threads underneath when parallel execution is required.
As of now (Jan 2021) the Project Loom work is still at the prototyping stage, with (AFAIK) no Java version targeted for the release.
<hr />
I've done a bit of digging to see how a Java thread's stack really gets allocated. In the case of OpenJDK 6 on Linux, the thread stack is allocated by the call to <code>pthread_create</code> that creates the native thread. (The JVM does not pass <code>pthread_create</code> a preallocated stack.)
Then, within <code>pthread_create</code> the stack is allocated by a call to <code>mmap</code> as follows:
<pre><code>mmap(0, attr.__stacksize, 
 PROT_READ|PROT_WRITE|PROT_EXEC, 
 MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
</code></pre>
According to <code>man mmap</code>, the <code>MAP_ANONYMOUS</code> flag causes the memory to be initialized to zero.
Thus, even though it might not be essential that new Java thread stacks are zeroed (per the JVM spec), in practice (at least with OpenJDK 6 on Linux) they are zeroed.

blocks|key|3191678|text|理论上，这取决于JVM。在实践中，每个线程都有相对较大的堆栈内存(默认情况下，我认为是256KB)。此外，线程被实现为OS线程，因此创建它们涉及OS调用，即上下文切换。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3191679|一定要认识到，计算中的“昂贵”总是非常相对的。与大多数对象的创建相比，线程创建的开销非常大，但相对于随机的硬盘寻道，线程创建的开销并不大。您不必不惜一切代价避免创建线程，但每秒创建数百个线程并不是明智之举。在大多数情况下，如果您的设计需要大量线程，则应使用大小有限的线程池。|3191680|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|$]]

In theory, this depends on the JVM. In practice, every thread has a relatively large amount of stack memory (256 KB per default, I think). Additionally, threads are implemented as OS threads, so creating them involves an OS call, i.e. a context switch.

Do realize that "expensive" in computing is always very relative. Thread creation is very expensive relative to the creation of most objects, but not very expensive relative to a random harddisk seek. You don't have to avoid creating threads at all costs, but creating hundreds of them per second is not a smart move. In most cases, if your design calls for lots of threads, you should use a limited-size thread pool.

blocks|key|274337|text|创建Threads需要分配相当数量的内存，因为它必须创建两个新堆栈(一个用于java代码，一个用于本机代码)。通过对Executor的多个任务重用线程，使用Executors/Thread池可以避免开销。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|274338|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executor.html|1|https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors.html^0|2|7|1M|8|0|26|9|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@$9|S|A|T|1|U]|$9|V|A|W|1|X]]|E|$]]|$1|F|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]]|G|$H|$5|I|J|K|E|$L|M]]|N|$5|I|J|K|E|$L|O]]]]

Creating <code>Threads</code> requires allocating a fair amount of memory since it has to make not one, but two new stacks (one for java code, one for native code). Use of <a href="https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors.html" rel="nofollow noreferrer">Executors</a>/Thread Pools can avoid the overhead, by reusing threads for multiple tasks for <a href="https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executor.html" rel="nofollow noreferrer">Executor</a>.

blocks|key|275861|text|有两种线程：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|275862|275863|Proper线程：这些是围绕底层操作系统的线程工具的抽象。因此，创建线程的开销与系统创建线程的开销一样大--总是有一个JVM线程：由overhead.|ordered-list-item|offset|length|style|BOLD|275864|"Green“创建和调度，这些开销更低，但是不会出现适当的并行化。这些线程的行为类似于线程，但在操作系统的JVM线程中执行。据我所知，它们并不经常被使用。|275865|275866|在线程创建开销中，我能想到的最大因素是为线程定义的堆栈大小的。线程堆栈大小可以在运行虚拟机时作为参数传递。|275867|除此之外，线程的创建主要依赖于操作系统，甚至依赖于VM实现。|275868|现在，让我指出一点:如果您计划每秒触发2000线程，那么创建线程的开销是很大的。JVM不是为处理而设计。如果你有几个稳定的员工，他们不会被一次又一次地解雇和杀害，那就放松吧。|275869|entityMap^0|0|0|0|8|0|0|25|0|0|0|1H|0|0|U|0|0|2F|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|W|8|@$F|X|G|Y|H|I]]|9|@]|A|$]]|$1|J|3|K|5|E|7|Z|8|@$F|10|G|11|H|I]]|9|@]|A|$]]|$1|L|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|13|8|@$F|14|G|15|H|I]]|9|@]|A|$]]|$1|O|3|P|5|6|7|16|8|@$F|17|G|18|H|I]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|19|8|@$F|1A|G|1B|H|I]]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|T|$]]

There are two kinds of threads:

<ol>
<li>Proper threads: these are abstractions around the underlying operating system's threading facilities. Thread creation is, therefore, as expensive as the system's -- there's always an overhead.</li>
<li>"Green" threads: created and scheduled by the JVM, these are cheaper, but no proper paralellism occurs. These behave like threads, but are executed within the JVM thread in the OS. They are not often used, to my knowledge.</li>
</ol>

The biggest factor I can think of in the thread-creation overhead, is the stack-size you have defined for your threads. Thread stack-size can be passed as a parameter when running the VM.

Other than that, thread creation is mostly OS-dependent, and even VM-implementation-dependent.

Now, let me point something out: creating threads is expensive if you're planning on firing 2000 threads per second, every second of your runtime. The JVM is not designed to handle that. If you'll have a couple of stable workers that won't be fired and killed over and over, relax.

blocks|key|2977987|text|显然，问题的症结在于“昂贵”是什么意思。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2977988|线程需要创建一个堆栈并基于run方法初始化该堆栈。|2977989|它需要设置控制状态结构，例如，它处于什么状态:可运行、正在等待等。|2977990|在设置这些东西时，可能会有大量的同步。|2977991|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|$]]

Obviously the crux of the question is what does 'expensive' mean. 

A thread needs to create a stack and initialize the stack based on the run method.

It needs to set up control status structures, ie, what state it's in runnable, waiting etc.

There's probably a good deal of synchronization around setting these things up.

blocks|key|2978028|text|其他人已经讨论了线程化的成本来自哪里。这个答案涵盖了为什么创建线程与许多操作相比没有那么昂贵，但与任务执行替代方案相比相对昂贵，后者相对便宜。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2978029|在另一个线程中运行任务的最明显的替代方案是在同一线程中运行该任务。对于那些认为线程越多越好的人来说，这是很难理解的。逻辑是，如果将任务添加到另一个线程的开销大于您节省的时间，则在当前线程中执行该任务可能会更快。|2978030|另一种选择是使用线程池。线程池可以更高效，原因有两个。1)它重用了已经创建的线程。2)您可以调整/控制线程的数量，确保您的性能达到最佳。|2978031|下面的程序打印....|2978032|Time+for+a+task+to+complete+in+a+new+Thread+71.3+us
Time+for+a+task+to+complete+in+a+thread+pool+0.39+us
Time+for+a+task+to+complete+in+the+same+thread+0.08+us
Time+for+a+task+to+complete+in+a+new+Thread+65.4+us
Time+for+a+task+to+complete+in+a+thread+pool+0.37+us
Time+for+a+task+to+complete+in+the+same+thread+0.08+us
Time+for+a+task+to+complete+in+a+new+Thread+61.4+us
Time+for+a+task+to+complete+in+a+thread+pool+0.38+us
Time+for+a+task+to+complete+in+the+same+thread+0.08+us|code-block|syntax|javascript|2978033|这是对一个微不足道的任务的测试，它暴露了每个线程选项的开销。(此测试任务实际上是在当前线程中执行得最好的那类任务。)|2978034|final+BlockingQueue<Integer>+queue+=+new+LinkedBlockingQueue<Integer>();
Runnable+task+=+new+Runnable()+{
++++@Override
++++public+void+run()+{
++++++++queue.add(1);
++++}
};

for+(int+t+=+0;+t+<+3;+t%2B%2B)+{
++++{
++++++++long+start+=+System.nanoTime();
++++++++int+runs+=+20000;
++++++++for+(int+i+=+0;+i+<+runs;+i%2B%2B)
++++++++++++new+Thread(task).start();
++++++++for+(int+i+=+0;+i+<+runs;+i%2B%2B)
++++++++++++queue.take();
++++++++long+time+=+System.nanoTime()+-+start;
++++++++System.out.printf("Time+for+a+task+to+complete+in+a+new+Thread+%25.1f+us%25n",+time+/+runs+/+1000.0);
++++}
++++{
++++++++int+threads+=+Runtime.getRuntime().availableProcessors();
++++++++ExecutorService+es+=+Executors.newFixedThreadPool(threads);
++++++++long+start+=+System.nanoTime();
++++++++int+runs+=+200000;
++++++++for+(int+i+=+0;+i+<+runs;+i%2B%2B)
++++++++++++es.execute(task);
++++++++for+(int+i+=+0;+i+<+runs;+i%2B%2B)
++++++++++++queue.take();
++++++++long+time+=+System.nanoTime()+-+start;
++++++++System.out.printf("Time+for+a+task+to+complete+in+a+thread+pool+%25.2f+us%25n",+time+/+runs+/+1000.0);
++++++++es.shutdown();
++++}
++++{
++++++++long+start+=+System.nanoTime();
++++++++int+runs+=+200000;
++++++++for+(int+i+=+0;+i+<+runs;+i%2B%2B)
++++++++++++task.run();
++++++++for+(int+i+=+0;+i+<+runs;+i%2B%2B)
++++++++++++queue.take();
++++++++long+time+=+System.nanoTime()+-+start;
++++++++System.out.printf("Time+for+a+task+to+complete+in+the+same+thread+%25.2f+us%25n",+time+/+runs+/+1000.0);
++++}
}
}|2978035|正如你所看到的，创建一个新的线程只需要大约70微秒，这在许多用例中是微不足道的，如果不是大多数的话。相对而言，它比替代方案更昂贵，对于某些情况，线程池或根本不使用线程是更好的解决方案。|2978036|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|X|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|Y|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|10|8|@]|9|@]|A|$K|L]]|$1|Q|3|R|5|6|7|11|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

Others have discussed where the costs of threading come from. This answer covers why creating a thread is not that expensive compared to many operations, but relatively expensive compared to task execution alternatives, which are relatively less expensive.

The most obvious alternative to running a task in another thread is to run the task in the same thread. This is difficult to grasp for those assuming that more threads are always better. The logic is that if the overhead of adding the task to another thread is greater than the time you save, it can be faster to perform the task in the current thread.

Another alternative is to use a thread pool. A thread pool can be more efficient for two reasons. 1) it reuses threads already created. 2) you can tune/control the number of threads to ensure you have optimal performance.

The following program prints....

<pre><code>Time for a task to complete in a new Thread 71.3 us
Time for a task to complete in a thread pool 0.39 us
Time for a task to complete in the same thread 0.08 us
Time for a task to complete in a new Thread 65.4 us
Time for a task to complete in a thread pool 0.37 us
Time for a task to complete in the same thread 0.08 us
Time for a task to complete in a new Thread 61.4 us
Time for a task to complete in a thread pool 0.38 us
Time for a task to complete in the same thread 0.08 us
</code></pre>

This is a test for a trivial task which exposes the overhead of each threading option. (This test task is the sort of task that is actually best performed in the current thread.)

<pre><code>final BlockingQueue&lt;Integer&gt; queue = new LinkedBlockingQueue&lt;Integer&gt;();
Runnable task = new Runnable() {
 @Override
 public void run() {
 queue.add(1);
 }
};

for (int t = 0; t &lt; 3; t++) {
 {
 long start = System.nanoTime();
 int runs = 20000;
 for (int i = 0; i &lt; runs; i++)
 new Thread(task).start();
 for (int i = 0; i &lt; runs; i++)
 queue.take();
 long time = System.nanoTime() - start;
 System.out.printf("Time for a task to complete in a new Thread %.1f us%n", time / runs / 1000.0);
 }
 {
 int threads = Runtime.getRuntime().availableProcessors();
 ExecutorService es = Executors.newFixedThreadPool(threads);
 long start = System.nanoTime();
 int runs = 200000;
 for (int i = 0; i &lt; runs; i++)
 es.execute(task);
 for (int i = 0; i &lt; runs; i++)
 queue.take();
 long time = System.nanoTime() - start;
 System.out.printf("Time for a task to complete in a thread pool %.2f us%n", time / runs / 1000.0);
 es.shutdown();
 }
 {
 long start = System.nanoTime();
 int runs = 200000;
 for (int i = 0; i &lt; runs; i++)
 task.run();
 for (int i = 0; i &lt; runs; i++)
 queue.take();
 long time = System.nanoTime() - start;
 System.out.printf("Time for a task to complete in the same thread %.2f us%n", time / runs / 1000.0);
 }
}
}
</code></pre>

As you can see, creating a new thread only costs ~70 &micro;s. This could be considered trivial in many, if not most, use cases. Relatively speaking it is more expensive than the alternatives and for some situations a thread pool or not using threads at all is a better solution.

The Java tutorials say that creating a Thread is expensive. But why exactly is it expensive? What exactly is happening when a Java Thread is created that makes its creation expensive? I'm taking the statement as true, but I'm just interested in mechanics of Thread creation in JVM. 

<blockquote>
 Thread lifecycle overhead. Thread creation and teardown are not free. The actual overhead varies across platforms, but thread creation takes time, introducing latency into request processing, and requires some processing activity by the JVM and OS. If requests are frequent and lightweight, as in most server applications, creating a new thread for each request can consume significant computing resources.
</blockquote>

From Java Concurrency in Practice 
By Brian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, Doug Lea 
Print ISBN-10: 0-321-34960-1

Why is creating a Thread said to be expensive?

数据结构

服务器

虚拟机

Linux

Java

Java教程说创建线程的代价很高。但它到底为什么昂贵呢？当创建Java线程时，究竟发生了什么，导致其创建成本高昂？我认为这句话是正确的，但我只对JVM中的线程创建机制感兴趣。线程生命周期开销。线程创建和拆卸不是免费的。实际开销因平台而异，但是创建线程需要时间，这会在请求处理中引入延迟，并且需要JVM和OS进行一些处理活...

问为什么创建一个Thread会很昂贵？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么创建一个Thread会很昂贵？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么创建一个Thread会很昂贵？
EN