后端调优基础——Tomcat调优 - 网站源码_资源分享

jdk8和Tomcat8.5是JDK和Tomcat的叙事诗级提升，间接把电单车变敞篷车，因此假如你却是采用的jdk7和Tomcat8.5之后的版，那能考量去线上换呵呵，但不晓得到时是CTO射杀你却是你射杀CTO

Tomcat的三种运转商业模式：

BIO:并行堵塞商业模式，Tomcat7及之后预设的商业模式，操控性最糟，Tomcat8.5后已舍弃NIO:并行非堵塞商业模式，Tomcat8及后预设的商业模式，操控性高，那时的主流商业模式AIO:触发器非堵塞商业模式，虽然纯触发器，操控性最低APR:须要附加加装倚赖库，从作业控制系统等级化解触发器IO，大幅的提升伺服器的处置和积极响应操控性，也是Tomcat运转高mammalian应用领域的必选商业模式,但采用十分困难，依赖控制系统的下层互联网包，项目组没C++天神和熟识Linux下层的天神却是别拿出秀了

非主流是NIO商业模式，他们主要就自学NIO商业模式的

实用性强化

server status

透过实用性能看见Tomcat管理工作页serve

他们须要修正呵呵命令行，conf/tomcat-users.xml和

webapps/manager/META-INF/context.xml。

找出conf/tomcat-users.xml

找出

webapps/manager/META-INF/context.xml，将附注注解掉，我早已注解掉了，这种就能远程访问web manager了：

image.png

透过server status能看见jvm的信息，还要很多的选项可供，例如应用领域程序列表、JVM信息、NIO模型等

image.png

禁用ajp协议

ajp协议是基于TCP协议的，Tomct采用ajp协议主要就是为了连接http apache伺服器的，http apache这个伺服器早已被Ngnix完爆了，假如没什么特殊癖好的话应该没人会用它了，但这个实用性会在程序中预设跑着十个线程，因此为了操控性把这个没用的功能去除，假如不是2020年2月之后下载的Tomcat的话，是没预设禁用的，因此须要手动禁掉

我的Tomcat是默认禁止的，我在实用性中开启了ajp,他们看见这里跑了十个线程，跑了线程又用不到，浪费CUP的操控性

image.png

在conf/server.xml中把这个实用性注解了就禁止掉ajp了（假如你有特殊的癖好，想打开ajp，就把注解打开，并且把secretRequired=”true”修正为secretRequired=””）

image.png

重启伺服器，查看server status，ajp早已没了

image.png

自定义Tomcat线程池

Tomcat须要给每一个请求创建线程，Tomcat预设的线程池最大线程数是200，核心线程数是10，如何mammalian高的场景，Tomcat就得不断的创建和销毁线程，因此就得自定义线程池提升核心线程数，这种能帮助他们提升操控性。但假如不是是连接请求特别多的场景，最后别乱改，核心线程是须要占用内存的

先看看他们没修正前的状态，我采用Jvisualvm工具监控Tomcat的线程状态，他们看见这里预设是十个线程，虽然我用的是Tomcat8.5因此运转商业模式预设是nio商业模式，线程的前缀是exec,记住这个名字后面用到的

image.png

修正server.xml文件，打开Executor的注解，我实用性的参数是：最大线程数150，核心线程数15，线程池名称，每个线程的前缀。

为了区别，我把线程的前缀改为tzb-nb-，接着把预设的连接器实用性注解掉，打开下面的连接器，让自定义的连接线程池生效

image.png

重启伺服器，查看Jvisualvm，他们看见连接池早已生效了，整好十五个

image.png

Tomcat线程模型

他们主要就讲Tomcat8后的NIO,因为NIO才是非主流，Tomcat的线程有很多，主线程叫做main是负责启动和关闭

Tomcat的主要就线程

看监控工具能看见Tomcat的主要就线程

Tomcat的主要就线程

Acceptor

采用NIO的原生ServerSocketChannel的accept()方法监听客户的连接请求，但这个ServerSocketChannel是设置堵塞的，因此当没连接请求来时，线程会堵塞在accept方法上。ServerSocketChannel设置的TCP连接队列大小预设是100，TCP连接队列就是把当前连接信息存放到全连接队列中，队列中的连接信息等待ServerSocket.accpt()处置，Acceptor队列由acceptCount控制，但Tomcat保持的通道数预设是10000，也就是ServerSocket.accpt()进去的通道Tomcat能保持10000个，由maxConnections控制hronizedStack中，SynchronizedStack内部是数组，然后队列里的PollerEvent等待Poller线程来注册处置，Poller线程内部就是采用了NIO中的Selector多路复用器，PollerEvent对象主要就是装载了SocketChanel和注册事件OP_REGISTER在Poller内部其实就是给Selector注册OP_READ，PollerEvent其实本身也是个线程。Poller线程是队列的消费者，Acceptor是生产者。这个Acceptor线程预设只有1个，但能在Tomcat中实用性数量

public void bind() throws Exception { if (!getUseInheritedChannel()) { //Acceptor的ServerSocketChannel serverSock = ServerSocketChannel.open(); socketProperties.setProperties(serverSock.socket()); InetSocketAddress addr = (getAddress()!=null? new InetSocketAddress(getAddress(),getPort()):new InetSocketAddress(getPort())); serverSock.socket().bind(addr,getAcceptCount());//getAcceptCount()预设是100 } else { //……………………….省略 //设置为堵塞的连接监听通道 serverSock.configureBlocking(true); //……………………….省略 protected final void startAcceptorThreads() { //Acceptor的线程个数，这个是能透过命令行实用性的 int count = getAcceptorThreadCount(); //创建Acceptor线程 acceptors = new Acceptor[count]; for (int i = 0; i < count; i++) { acceptors[i] = createAcceptor(); String threadName = getName() + “-Acceptor-” + i; acceptors[i].setThreadName(threadName); Thread t = new Thread(acceptors[i], threadName); t.setPriority(getAcceptorThreadPriority()); t.setDaemon(getDaemon()); //启动Acceptor线程 t.start(); } } protected class Acceptor extends AbstractEndpoint.Acceptor { //……………………….省略 @Override public void run() { //……………………….省略 while (running) { //计数+1，达到最大值则等待,tomcat设定个最大连接数是10000，达到这个阈值后，就会拒绝连接请求，进行堵塞，这个是用AQS堵塞队列实现的 countUpOrAwaitConnection(); SocketChannel socket = null; try { //ServerSocketChannel开始监听连接 socket = serverSock.accept(); //……………………….省略 if (running && !paused) { if (!setSocketOptions(socket)) {//setSocketOptions设置socket的方法 closeSocket(socket); } //……………………….省略 private void closeSocket(SocketChannel socket) { //断开连接计数器将会减1 countDownConnection(); protected boolean setSocketOptions(SocketChannel socket) { try { //将监听到的SocketChannel 设置为非堵塞 socket.configureBlocking(false); Socket sock = socket.socket(); //……………………….省略 //注册到ClientPoller的方法 getPoller0().register(channel); //……………………….省略 } public void register(final NioChannel socket) { //……………………….省略 if ( r==null) //封装成PollerEvent，与OP_REGISTER注册事件绑定 r = new PollerEvent(socket,ka,OP_REGISTER); else r.reset(socket,ka,OP_REGISTER); //添加到队列 addEvent(r); } public static class PollerEvent implements Runnable { //……………………….省略 @Override public void run() { //注册事件，他们看见注册事件其实就是OP_READ读事件 if (interestOps == OP_REGISTER) { try { //将事件和通道注册到ClientPoller中的多路复用器中 socket.getIOChannel().register( socket.getPoller().getSelector(), SelectionKey.OP_READ, socketWrapper);

ClientPoller

Tomcat8之后的NIO商业模式比Tomcat7以前强悍就是因为这个ClientPoller，ClientPoller是实现了Runnable，ClientPoller线程内部有一个jdk原生的Selector对象，也就是NIO的多路复用器。ClientPoller线程从队列SynchronizedQueue中取出PollerEvent逐一启动，启动后PollerEvent将SocketChanel和对应的事件逐一注册注册到ClientPoller的Selector，Selector找出SocketChanel中就绪的SelectionKey，将SelectionKey和事件类型交给工作线程Exec进行处置。整个过程就是典型的NIO实现。Tomcat预设启动Math.min(2,Runtime.getRuntime().availableProcessors())个ClientPoller线程，绝大部分的情况是2个ClientPoller，也就是两个Selector须要处置成千上万的事件，非常繁忙

Poller的run方法部分代码

//processKey源码大致逻辑，省略详细代码 protected void processKey(SelectionKey sk, NioSocketWrapper attachment) { //……………………….省略 if ( close ) { //……………………….省略 } else if ( sk.isValid() && attachment != null ) { if (sk.isReadable() || sk.isWritable() ) { // 写事件 if ( attachment.getSendfileData() != null ) { processSendfile(sk,attachment, false); } else { if (sk.isReadable()) { //读事件 if (!processSocket(attachment, SocketEvent.OPEN_READ, true)) { closeSocket = true; } } if (!closeSocket && sk.isWritable()) { // 写事件 if (!processSocket(attachment, SocketEvent.OPEN_WRITE, true)) { closeSocket = true; } } if (closeSocket) { ………………………. // 关闭通道 } ……………………………. }

NioBlockingSelector.BlockPoller

NioBlockingSelector主要就处置socketChanel的写操作，也就是servlet的回写过程，NioBlockingSelector有两个对象BlockPoller和Selector叫做sharedSelector。BlockPoller中也有一个Selector对象，这个Selector主要就是在blockingSelector.write时假如出现写失败就把socketChanel注册到BlockPoller的Selector不在占用ClientPoller的时间片，然后就利用CountDownLatch进行堵塞这是Tomcat预设的写操作过程，在BlockPoller的Selector注册的socketChanel之后的读写操作都是由这个Selector堵塞轮询。同时NioBlockingSelector是NioSelectorPool中一个成员对象，NioSelectorPool中有两个成员对象NioBlockingSelector和一个Selector叫做SHARED_SELECTOR，SHARED_SELECTOR主要就在非预设的写过程中处置由ClientPoller轮询的socketChanel出现写失败时，为了节省ClientPoller宝贵的时间片socketChanel写事件会注册到SHARED_SELECTOR上，这个SHARED_SELECTOR是叫做辅Selector，值得一提的是NioSelectorPool的SHARED_SELECTOR、NioBlockingSelector的sharedSelector、BlockPoller的Selector都是同一对象，这个辅Selector轮询出现写事件失败的socketChanel，由辅Selector负责这些socketChanel之后的读写事件，这种减少线程间的切换，同时还可减轻主Selector的负担。

public class NioSelectorPool { //SHARED 预设是true protected static final boolean SHARED = Boolean.parseBoolean(System.getProperty(“org.apache.tomcat.util.net.NioSelectorShared”, “true”)); protected NioBlockingSelector blockingSelector; protected volatile Selector SHARED_SELECTOR; //……………………省略 public int write(ByteBuffer buf, NioChannel socket, Selector selector, long writeTimeout, boolean block) throws IOException { if ( SHARED && block ) {//block 和SHARED 是预设true，因此写事件预设走这里 //堵塞写操作 return blockingSelector.write(buf,socket,writeTimeout); } //……………………省略 if ( keycount > 0 ) { //only write if we were registered for a write //写操做，cnt -1为失败 cnt = socket.write(buf); //write the data if (cnt > 0) { continue; } //非堵塞写 if (cnt==0 && (!block)) break; //dont block } if ( selector != null ) { //非堵塞写失败后重新注册到SHARED_SELECTOR，不占用ClientPoller的时间片 if (key==null) key = socket.getIOChannel().register(selector, SelectionKey.OP_WRITE); else key.interestOps(SelectionKey.OP_WRITE); } else if (writeTimeout<0) { //SHARED_SELECTOR轮询 keycount = selector.select(); } else { keycount = selector.select(writeTimeout); } } //……………………………………………………………省略 ublic class NioBlockingSelector { protected Selector sharedSelector; protected BlockPoller poller; //堵塞写 public int write(ByteBuffer buf, NioChannel socket, long writeTimeout) throws IOException { SelectionKey key = socket.getIOChannel().keyFor(socket.getPoller().getSelector()); try { while ( (!timedout) && buf.hasRemaining()) { if (keycount > 0) { //only write if we were registered for a write int cnt = socket.write(buf); //write the data written += cnt; //写操做，cnt -1为失败 if (cnt > 0) { time = System.currentTimeMillis(); //reset our timeout timer continue; //we successfully wrote, try again without a selector } } try { if ( att.getWriteLatch()==null || att.getWriteLatch().getCount()==0) att.startWriteLatch(1); //失败则重新注册写事件到BlockPoller 中 poller.add(att,SelectionKey.OP_WRITE,reference); //利用CountDownLatch进行堵塞 if (writeTimeout < 0) { att.awaitWriteLatch(Long.MAX_VALUE,TimeUnit.MILLISECONDS); } else { att.awaitWriteLatch(writeTimeout,TimeUnit.MILLISECONDS); } }

Exec

Exec是一个线程池很多博客叫它为Work,预设的线程名称是和server.xml中的一致，核心线程预设是10，最大线程数是200，能透过我r的service方法解析HTTP协议，将http协议解析成键值对放入request，最终调用CoyoteAdapter的service方法将request和response传入Tomcat的各种容器中执行servlet的业务逻辑。

image.png

//工作线程执行run处置socketChanel public boolean processSocket(SocketWrapperBase<S> socketWrapper, SocketEvent event, boolean dispatch) { try { if (socketWrapper == null) { return false; } //将Socket封装到这个对象，然后扔给工作线程执行 SocketProcessorBase<S> sc = processorCache.pop(); if (sc == null) { sc = createSocketProcessor(socketWrapper, event); } else { sc.reset(socketWrapper, event); } //工作线程，他们在命令行中实用性的Executor,不配预设是10个。最大数200 Executor executor = getExecutor(); //工作线程执行工作 if (dispatch && executor != null) { executor.execute(sc); } else { sc.run(); } //工作线程执行的东西，主要就是三次握手后开始解析HTTP,然后关闭socket，省略部分代码 protected class SocketProcessor extends SocketProcessorBase<NioChannel> { public SocketProcessor(SocketWrapperBase<NioChannel> socketWrapper, SocketEvent event) { super(socketWrapper, event); } @Override protected void doRun() { if (handshake == 0) {//三次握手已完成 SocketState state = SocketState.OPEN; // Process the request from this socket if (event == null) { state = getHandler().process(socketWrapper, SocketEvent.OPEN_READ); } else { state = getHandler().process(socketWrapper, event); } if (state == SocketState.CLOSED) { close(socket, key); } …………………….. //逻辑处置主要就是调用了这给ConnectionHandler处置socket的数据包 protected static class ConnectionHandler<S> implements AbstractEndpoint.Handler<S> { //省略 ……………………………………….. //处置socket数据包，将HTTP其解析成request 对象，传给Tomcat容器 @Override public SocketState process(SocketWrapperBase<S> wrapper, SocketEvent status) { //省略 ……………………………………….. do { //省略 ……………………………………….. state = processor.process(wrapper, status);//真正继续数据包的方法，这个processor是AbstractProcessorLight 类型的，但process方法主要就是调用子类Http11Processor类实现的service进行处置 //省略 ……………………………………….. } } }

点进process方法，里面调用了service

public abstract class AbstractProcessorLight implements Processor { @Override public SocketState process(SocketWrapperBase<?> socketWrapper, SocketEvent status) //省略 ……………………………………….. throws IOException { } else if (status == SocketEvent.OPEN_READ) { //这里是调用Http11Processor 的service方法 state = service(socketWrapper); } //省略 ………………………………………..

Http11Processor 的service方法进行系列的解析各种

public class Http11Processor extends AbstractProcessor { //省略 ……………………………………….. @Override public SocketState service(SocketWrapperBase<?> socketWrapper) throws IOException { //省略 ……………………………………….. //经过一系列的解析和设置后，将http的各种信息都存放到request中调用CoyoteAdapter的service方法将request, response传递到Tomcat容器 getAdapter().service(request, response); //省略 ……………………………………….. } }

Tomcat线程模型组件类的结构图

Tomcat线程模型动态图

NioEndpoint组件

NioEndpoint是Tomcat的NIO关键的类，要理解tomcat的nio最主要就就是对NioEndpoint的理解

image.png

有空得自己去看看《Tomcat的内核设计剖析》

image.png

NioEndpoint它一共包含LimitLatch、Acceptor、Poller、SocketProcessor、Excutor5个部分。LimitLatch是连接控制器，它负责维护连接数的计算，nio商业模式下预设是10000，达到这个阈值后，就会拒绝连接请求。Acceptor负责接收连接，预设是1个线程来执行，将请求的事件注册到事件列表。有Poller来负责轮询，Poller线程数量是cpu的核数Math.min(2,Runtime.getRuntime().availableProcessors())。由Poller将就绪的事件生成SocketProcessor同时交给Excutor去执行。Excutor线程池的大小就是他们在Connector节点实用性的maxThreads的值。在Excutor的线程中，会完成从socket中读取http request，解析成HttpServletRequest对象，分派到相应的servlet并完成逻辑，然后将response透过socket发回client。在从socket中读数据和往socket中写数据的过程，并没像典型的非堵塞的NIO的那样，注册OP_READ或OP_WRITE事件到主Selector，而是间接透过socket完成读写，这时是堵塞完成的，但在timeout控制上，采用了NIO的Selector机制，但这个Selector并不是Poller线程维护的主Selector，而是BlockPoller线程中维护的Selector，称之为辅Selector

NioEndpoint Nio的时序图

Tomcat文件传输

sendfile零拷贝：

在普通的输入输出流进行读写时，实际上是进行了多次上下文切换，应用领域读取数据时，先在内核态将数据从磁盘读取到内核缓存，再切换到用户态将数据从内核缓存读取到用户缓存，在用户态对数据进行加工，然后再从用户态切换回内核态，将用户缓存数据拷贝到内核缓存中，然后读到socket中再到网卡

sendfile实质是linux控制系统中一项强化技术，用以发送文件和互联网通信时，减少用户态空间与磁盘倒换数据，而间接在内核级做数据拷贝，在Tomcat中是能采用sendfile对一些静态数据如：图片、文件等进行传输，这个sendfile是在Tomcat是预设打开的，能有效的提升Tomcat的传输操控性

零拷贝

compression文件压缩：

compression能对传输文件进行压缩有效化解文件传输的带宽问题，在Tomcat不支持图片压缩，因为要进行上层的用户态数据加工因此与sendfile互斥，Tomcat预设关闭，开启的话Tomcat会调用Filter利用jdk解压缩流进行解压缩

//源码中compression支持的压缩格式中没图片 private String compressibleMimeType = “text/html,text/xml,text/plain,text/css,” + “text/javascript,application/javascript,application/json,application/xml”;

Accept-Encoding 和Content-Encoding

Accept-Encoding 和Content-Encoding是HTTP中用来对采用哪种编码格式传输正文进行协定的一对头部字段。浏览器发送请求时，会在Request-heads携带Accept-Encoding会说明自己支持的编码列表，服务端在接收到请求后，从中挑选出一种用来对积极响应信息进行编码，并透过Response-heads携带Content-Encoding来说明服务端选择的编码信息，浏览器在拿到积极响应正文后，依据Content-Encoding进行解压。绝大部分是gzip格式

Tomcat重要实用性参数

server.xml

自定义线程池他们上面讲过了，那时有了一定的此基础更好介绍了

Executor标签是专门实用性Exec线程池的，专门用于处置多路复用器传递进来的socketChanel，他们上面介绍过了

<Executor name=”tomcatThreadPool” namePrefix=”tzb-nb-” maxThreads=”1000″ minSpareThreads=”30″ maxIdleTime=”60000″ maxQueueSize=”1000000″ className=”org.apache.catalina.core.StandardThreadExecutor”/> name：线程池名称，用于 Connector中指定。 namePrefix：所创建的每个线程的名称前缀。 maxThreads：池中最大线程数。 minSpareThreads：核心池线程数。 maxIdleTime：线程空闲时间，超过该时间后，非核心线程会被销毁，预设值为6000（1分钟），单位毫秒。 maxQueueSize：在被执行前最大线程排队数目，任务数超出会执行拒绝策略，预设为Int的最大值 className：线程池实现类，未指定情况下，预设实现类为org.apache.catalina.core.StandardThreadExecutor。假如想采用自定义线程池首先须要实现 org.apache.catalina.Executor接口。

Connector用于实用性Tomcat运转商业模式、Acceptor、CilentPoller、sendfile、是否开启文件压缩

我只列出几个有意思的

port：代表Tomcat监听端口，也就是网站的访问端口，预设为8080，能根据须要改成其他。 protocol：运转商业模式，可选类型有三种，分别为BIO，NIO，AIO和APR。 protocol=”org.apache.coyote.http11.Http11NioProtocol” //NIO protocol=”org.apache.coyote.http11.Http11Nio2Protocol” //AIO protocol=”org.apache.coyote.http11.Http11AprProtocol” //ARP acceptCount：就是Acceptor线程工作时通道的长度也就是前面说的SynchronizedStack，当请求PollerEvent超出队列时请求就会被拒绝，预设是100。一般是设置的跟 maxThreads一样或一半，此值设置的过大会导致排队的请求超时而未被处置。因此这个值应该是主要就根据应用领域的访问峰值与平均值来权衡实用性。 acceptorThreadCount:Acceptor线程的数量,预设是1，假如在多核CPU架构下，此值能设置为2，官方不建议设定超过2个的值。 maxConnections：tomcat最大连接数也就是上面说的LimctionTimeout：当请求早已被接受，但未被处置，也就是等待中的超时时间。单位为毫秒，预设值为60000。 executor：就是把executor标签的内容引过来，不要它的话能把executor的内容复制到这里 URIEncoding：URL编码字符集。 pollerThreadCount：ClientPoller的线程数，预设为2。官方不建议设置大于2的值，因为锁的竞争会导致操控性下降，事实上一个线程也足够快速。 useSendfile：是否开启sendfile特性，预设为true。对于web应用领域而言，通常project中还会包含一定数量的静态资源，比如图片、CSS、js、html等，sendfile在一定程度上能提升操控性。 compression：是否开启压缩，这个属性与useSendfile互斥，useSendfile开启了，这个认关闭，compression是预设关闭的 compressionMinSize：假如compression=”on”，则启用此项。被压缩前数据的最小值，也就是超过这个值后才被压缩。假如没指定，这个属性预设为“2048”（2K），单位为byte。

实战：

image.png

他们看见Acceptor线程线程是3个、Client线程是5个，exec线程是15个和我上图的实用性一致

image.png

catalina.sh

采用JAVA_OPTS实用性JVM参数

//例如： JAVA_OPTS=”-Dfile.encoding=UTF-8 -server -Xms2048m -Xmx2048m -XX:NewSize=512m -XX:MaxNewSize=1024m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:MaxTenuringThreshold=10 -XX:NewRatio=2 -XX:+DisableExplicitGC”

一般说来，您应该使用物理内存的 80% 作为堆大小。说明：以上两个参数关系到tomcat承受的访问操控性，但也要根据伺服器实际内存情况设定。有人建议Xms和Xmx的值取成一样比较好，说是能加快内存回收速度。Xms和Xmx这两个值的大小一般根据须要进行实用性。初始化堆的大小执行了虚拟机在启动时向控制系统申请的内存的大小。一般而言，这个参数不重要。但有的应用领域程序在大负载的情况下会急剧地占用更多的内存，此时这个参数就是显得很重要，假如虚拟机启动时实用性采用的内存比较小而在这种情况下有许多对象进行初始化，虚拟机就必须重复地增加内存来满足采用。虽然这种原因，他们一般把-Xms和-Xmx设为相同大，而堆的最大值受限于控制系统采用的物理内存。一般采用数据量较大的应用领域程序会采用持久对象，内存采用有可能迅速地增长。当应用领域程序须要的内存超出堆的最大值时虚拟机就会提示内存溢出，并且导致应用领域服务崩溃。因此一般建议堆的最大值实用性为可用内存的最大值的80%。另外须要考量的是Java提供的垃圾回收机制。虚拟机的堆大小决定了虚拟机花费在收集垃圾上的时间和频度。收集垃圾能够接受的速度和应用领域有关，应该透过分析实际的垃圾收集的时间和频率来调整。假如堆的大小很大，那么完全垃圾收集就会很慢，但频度会降低。假如您把堆的大小和内存的须要一致，完全收集就很快，但会更加频繁。调整堆大小的的目的是最小化垃圾收集的时间，以在特定的时间内最大化处置客户的请求。在基准测试的时候，为确保最好的操控性，要把堆的大小设大，确保垃圾收集不在整个基准测试的过程中出现。假如控制系统花费很多的时间收集垃圾，请减小堆大小。一次完全的垃圾收集应该不超过 3-5 秒。假如垃圾收集成为瓶颈，那么须要指定代的大小，检查垃圾收集的周详输出，研究垃圾收集参数对操控性的影响。一般说来，您应该采用物理内存的 80% 作为堆大小。当增加处置器时，记得增加内存，因为分配能够并行进行，而垃圾收集不是并行的。