高并发请求服务器时，经常出现如下异常：java.lang.OutOfMemoryError: unable to create new native thread，对于此种情况，出现这种情况，是什么原因呢，又该如何解决呢



1、原因

问题的表象解释是，你的服务器的单个进程已经不能再创建更多的线程了， 

那为什么会出现这种情况呢？ 

原因有几种情况: 

1.你的应用创建了太多线程了，理论上讲，一个应用进程，创建多个线程，确实可以提高应用程序的并发能力，但线程的数量并不是越大，你的应用程序并发能力就越强的。 

2.你的服务器并不允许你的应用程序创建这么多线程，linux系统默认允许单个进程可以创建的线程数是1024个，你的应用创建超过这个数量，就会报java.lang.OutOfMemoryError: unable to create new native thread

2、解决方法

1.想办法降低你应用程序创建线程的数量，既然我们已经知道，线程的数量和应用程序并发能力不是正比，就得在应用层面，分析应用是否真的需要创建这么多线程，如果不是，果断改代码，将线程数降到最低 

2.对于有的应用，确实需要创建很多线程，远超过linux系统的默认1024个线程的限制，可以通过修改linux服务器配置，扩大linux默认限制 

3.修改应用程序单线程占用的堆栈大小，线程越多，占用的堆栈空间就越多，如果内存空间不够大，自然也无法创建更多的线程。如果你的老板或客户足够阔气，要多少内存给多少，可以忽略这个

2.1、降低应用程序创建线程的数量

应用程序是你负责的，这个只能你自己想办法解决 

原则有几个： 

1.在必须用线程的情况下，如果可以用线程池的，尽量用线程池 

2.检查线程池默认开启线程的个数，如果只想开启一个线程，代码却设置了多个，如果有这种情况，坚决改之 

3.检查线程池的类型，newCachedThreadPool,newFixedThreadPool,newScheduledThreadPool，这几种线程池差别还是很大的，不能乱用 

4.检查线程泄漏，所谓线程泄漏，就是你只管生，不管死，只管创建，不管线程的销毁，结果线程的句柄你也没有管理起来，导致进程中创建了无数个僵尸线程，出现unable to create new native thread只是时间问题

2.2、修改Linux服务器配置

vi /etc/sysctl.conf
末尾追加下面的三行
vm.max_map_count = 1000000
kernel.pid_max = 1000000
kernel.threads-max = 1000000
保存后，执行sysctl -p使其生效



vi /etc/security/limits.d/90-nproc.conf
找到这一行，*     soft    nproc     1024
修改最后的数字为102400

退出登录工具(SecureCRT)，重新连接 执行ulimit -u 命令查看是否为修改后的值 

注意：此处的数字值不是随意改大都能生效，如果超出系统能设置的最大值时，系统自动以系统最大值为有效。 

附：系统最大值计算方法： 

default_nproc = total_memory/128K 

total_memory获取：cat /proc/meminfo |grep MemTotal，单位KB 

举例：



$ cat /proc/meminfo |grep MemTotal
MemTotal:       16425852 KB
$ echo "16425852 / 128"| bc 
128326

即该服务器所能设置的nproc最大值为128326



2.3、修改应用程序单线程占用的堆栈大小

配置你自己应用单个线程占用的内存资源，以java-web应用部署在tomcat中为例：

vi catalina.sh

找到JAVA_OPTS配置项



JAVA_OPTS="-Xms512m -Xmx1536m -XX:MaxNewSize=128m -XX:PermSize=128m -XX:MaxPermSize=256m"

在-Xmx1536m后添加“-Xss325k”参数，如下



JAVA_OPTS="-Xms512m -Xmx1536m -Xss325k -XX:MaxNewSize=128m -XX:PermSize=128m -XX:MaxPermSize=256m"

保存并重启tomcat

-Xss参数，是用于设置单线程占用的内存资源，该值并不是随意设置，jdkJDK5.0以后每个线程堆 栈大小为1M，以前每个线程堆栈大小为256K。根据应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一 个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。 

线程栈的大小是个双刃剑，如果设置过小，可能会出现栈溢出，特别是在该线程内有递归、大的循环时出现溢出的可能性更大，如果该值设置过大，就有影响到创建栈的数量，如果是多线程的应用，就会出现内存溢出的错误．

JVM可创建的最大线程数限制因素: 

线程堆栈大小——》进程的最大内存——》操作系统位数

原文链接 作者: Jakob Jenkov 译者: 李璟
有时候你可能需要并发地处理输入和输出。换句话说，你可能有超过一个线程处理输入和产生输出。比如，你有一个程序需要处理磁盘上的大量文件，这个任务可以通过并发操作提高性能。又比如，你有一个web服务器或者聊天服务器，接收许多连接和请求，这些任务都可以通过并发获得性能的提升。
如果你需要并发处理IO，这里有几个问题可能需要注意一下：
在同一时刻不能有多个线程同时从InputStream或者Reader中读取数据，也不能同时往OutputStream或者Writer里写数据。你没有办法保证每个线程读取多少数据，以及多个线程写数据时的顺序。
如果线程之间能够保证操作的顺序，它们可以使用同一个stream、reader、writer。比如，你有一个线程判断当前的输入流来自哪种类型的请求，然后将流数据传递给其他合适的线程做后续处理。当有序存取流、reader、writer时，这种做法是可行的。请注意，在线程之间传递流数据的代码应当是同步的。
注意：在Java NIO中，你可以让一个线程读写多个“channel”。比如，你有很多网络连接处于开启状态，但是每个连接中都只有少量数据，类似于聊天服务器，可以让一个线程监视多个频道(连接)。Java NIO是另一个话题了，会后续教程中介绍。

展开全部
一、背景综述
并发62616964757a686964616fe59b9ee7ad9431333365633863就是可以使用多个线程或进程，同时处理(就是并发)不同的操作。
高并发的时候就是有很多用户在访问，导致系统数据不正确、糗事数据的现象。对于一些大型网站，比如门户网站，在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。这几个解决思路在一定程度上意味着更大的投入。
使用一般的synchronized或者是lock或者是队列都是无法满足高并发的问题。
二、解决方法有三：
1.使用缓存
2.使用生成静态页面
html纯静态页面是效率最高、消耗最小的页面。我们可以使用信息发布系统来实现简单的信息录入自动生成静态页面，频道管理、权限管理和自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的信息发布系统CMS是必不可少的。
3.图片服务器分离
图片是最消耗资源的，僵图片和页面分离可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃。
3.写代码的时候减少不必要的资源浪费：不要频繁得使用new对象，对于在整个应用中只需要存在一个实例的类使用单例模式.对于String的连接操作,使用StringBuffer或者StringBuilder.对于utility类型的类通过静态方法来访问。
避免使用错误的方式,如Exception可以控制方法推出,但是Exception要保留stacktrace消耗性能,除非必要不要使用 instanceof做条件判断,尽量使用比的条件判断方式.使用JAVA中效率高的类,比如ArrayList比Vector性能好。)
使用线程安全的集合对象vector  hashtable
使用线程池

Web请求线程的状态
在开发中，突然想到了这样的一个问题， Java对每一次Web的请求，是否都会创建一条线程去进行处理呢？也就是说，当一个Class的方法同时有1000个请求访问时，线程是如何运作的呢？
解释上面的问题，首先需要说一下Web服务器处理请求的几种模式：
1、收到一个请求就处理，这个时候就不能处理新的请求，这种为阻塞 这个是单线程模型，无法并发，一个请求没处理完服务器就会阻塞，不会处理下一个请求。一般的服务器不会使用这种方式实现。
2、收到一个请求就新开一个线程去处理任务，主线程返回，继续处理下一个任务，这种为非阻塞。
首先纠正一个错误，这并不是非阻塞，它也是阻塞的。相对第一个模型来说，它解决了主线程阻塞的问题，有了一定程度的并发量，但是在每个新开的线程中还是阻塞的。如果100个人同时访问，将会开100个线程，那1000个人，10000个人呢？频繁开关线程很消耗资源，这样实现的服务器性能依然不高。
3、类似2的模型，但是不是每次收到请求就开一个新的线程，而是使用线程池。
如果不了解线程池，你可能会了解数据库连接池，由于频繁创建、关闭数据库连接会消耗资源，所以会用数据库连接池来保存一定数量的连接，如果需要就从连接池里取连接，不需要则放回连接池，不在频繁创建。线程池也是一样的道理，线程池管理多线程，性能比频繁创建线程高得多。这种方式实现的服务器性能会比2高。不过，它依然是阻塞的。线程池的线程数量通常有限制的，如果所有线程都被阻塞(例如网速慢，或者被人恶意占用连接)，那么接下来的请求将会排队等待。
4、基于Java NIO实现的服务器模型
上面说到的几种模型，都是基于BIO(阻塞IO)。而NIO则是非阻塞IO，它是基于IO多路复用技术(例如Reactor模式)实现，只需要一个线程或者少量线程，就可以处理大量请求。从性能上来说NIO实现的服务器并发性一般大于BIO，所以可以实现高性能的服务器。如果感兴趣，可以学习一些基于NIO的网络编程框架，例如Netty、MINA。
而我们最常见的Tomcat运行可以选择BIO或者NIO模型，原理分别对应上面的3和4两种方式。Tomcat默认是BIO方式运行，如果想要换成NIO，可以配置server.xml：
从性能上考虑建议使用NIO。
在实际开发中，如果是要求实时响应性比较高的系统，或者采用了类似Dubbo这种SOA微服务分布式的系统，一次请求的响应时间需要进行控制，这种情况下，如果代码执行到可能发生阻塞操作的地方(例如：查询数据量比较大的表、循环多次操作Redis Cache等)，往往就可能出现服务超时的问题(Timeout Exception)，对于这种情况，可以考虑采用线程池解决这个问题。
采用线程池的话，将线程池定义为全局静态对象，在方法中使用，可以将可预见的会发生阻塞操作的代码块部分放入线程池进行执行，如此这样，当主线程执行到线程池的部分，会执行线程池的run()方法，然后主线程会继续向下执行，直到最后直接返回结果，而阻塞的部分将在run()方法中执行，不会阻塞主线程的执行，这样可以达到一个异步非阻塞的快速响应。
转载自：https://blog.csdn.net/wtopps/article/details/71339295
如需转载请注明出处。