面试题总结 101-125

102.如何解决网站大规模并发访问带来的性能下降问题

一、服务器配置优化


我们需要根据应用服务器的性能和并发访问量的大小来规划应用服务器的数量。有一个使用原则是：单台应用服务器的性能不一定要求最好，但是数量一定要足够，最好能有一定的冗余来保障服务器故障。特别是，在高并发访问峰期间，适当增加某些关键应用的服务器数量。比如在某些高峰查询业务上，可以使用多台服务器，以满足用户每小时上百万次的点击量。


二、使用负载均衡技术


负载均衡技术是解决集中并发访问的核心技术,也是一种较为有效的解决网站大规模并发访问的方法。实现负载均衡技术的主要设备是负载均衡器服务器。例如，我们把网站部署到在两台不同的服务器之上(前提是要保证这2台或者多台服务器都可以正常运行网站程序)，这几台服务器之间通过安装特定的软件实现负载均衡。那么，某个时刻，当网站面临大规模访问时，用户的请求会通过负载均衡程序，根据不同服务器的繁忙和资源情况，自动分配到处理性能最优的服务器上，从而将大规模用户产生的高并发访问均衡地分流到各个服务器上。这样就能大大减轻单台服务器处理高并发请求，确保整个网站系统面临高负载时的可靠性。


三、数据库结构设计


这部分是程序层的问题，通常是由软件工程师进行负责，对SQL语句进行优化。我们可以采取的措施包括：对经常查询的数据库字段做索引、对数据库表进行分区操作(如对海量数据进行分区操作十分必要，例如针对按年份存取的数据，我们可以按年进行分区)、对数据库查询语句-SQL(减少冗余的数据库操作，提高查询效率)进行优化等。


四、中间件的优化


所谓的中间件，听起来会有点像很深的技术，其实就在我们身边，各位站长朋友经常在网站部署的时候用到的Apache、IIS、Tomcat、WebLogic都是中间件。中间件主要位于客户端/服务器的操作系统之上，负责计算机的资源管理和网络通讯。举个简单的例子，我们在部署JAVA项目的时候，通常都是用Tomcat中间件，那么Tomcat在默认情况下是不优化的，当在高并发的情况下，非常容易当机。关于Tomcat的优化给出以下几个建议(本人在实际项目开发过程中觉得较为重要的几点)：①线程池优化;②启动占用内存优化;③日志输出优化;④HTTP压缩优化;⑤配置文件优化。


上面举例的Tomcat中间件(也就是WEB服务器)只是一个例子，不同的网站采用不同的架构，那么对相应的中间件的优化也会有不同的方法，比如微软的IIS有相应的配置参数，所以具体的优化方法可以根据项目的需要，查阅中间件的官方文档说明进行参数设置，这样才能实现中间件的最优设置。


五、数据缓存技术的使用


现在大多数大型网站都有使用缓存技术，把用户经常使用到的数据通过缓存(Cache)技术进行管理，从而减轻服务器重新请求的压力，提高网站的访问速度。缓存技术有很多，这里我个人根据实际的项目经验，可以将其分成2种，即数据缓存和页面缓存。


①所谓的是数据缓存，指的是数据库的数据不是直接传输，而是将数据调用到内存，然后从内存中读取，从而可以大大提高读取速度。数据缓存技术有很多的方案，这里由于开源、高性能等特点，建议使用Memcache来设置数据缓存技术来加速动态web应用程序，减轻数据库负载。


②页面缓存一定程度上是针对公共页面，静态化也是页面缓存的一种，将用户经常访问的页面在服务器的相应目录下生成静态页面，当用户再次访问时，不需要对服务器进行动态请求，而只需要对缓存下来的html页面直接读取，这样访问的效率就可以得到有效的提高。


103.高并发优化建议
一些优化经验，首先学会用explain语句分析select语句，优化索引、表结构，其次，合理运用memcache等缓存，降低mysql的负载，

104.网络的七层协议：

 第一层，物理层
OSI模型最低层的“劳苦大众”。它透明地传输比特流，就是传输的信号。该层上的设备包括集线器、发送器、接收器、电缆、连接器和中继器。

第二层，数据链路层
这一层是和包结构和字段打交道的和事佬。一方面接收来自网络层（第三层）的数据帧并为物理层封装这些帧；另一方面数据链路层把来自物理层的原始数据比特封装到网络层的帧中。起着重要的中介作用。
数据链路层由IEEE802规划改进为包含两个子层：介质访问控制（MAC）和逻辑链路控制（LLC）。
智能集线器、网桥和网络接口卡（NIC）等就驻扎在这一层。但是网络接口卡它同样具有物理层的一些编码功能等。

第三层，网络层
这一层干的事就比较多了。它工作对象，概括的说就是：电路、数据包和信息交换。
网络层确定把数据包传送到其目的地的路径。就是把逻辑网络地址转换为物理地址。如果数据包太大不能通过路径中的一条链路送到目的地，那么网络层的任务就是把这些包分成较小的包。
这些光荣的任务就派给了路由器、网桥路由器和网关。
以后几层属于较高层，通常驻留在跨网络相互通信的计算机中，而不象以上几层可以独自为阵。设备中只有网关可跨越所有各层。

第四层，传输层。
确保按顺序无错的发送数据包。传输层把来自会话层的大量消息分成易于管理的包以便向网络发送。

第五层，会话层。
在分开的计算机上的两种应用程序之间建立一种虚拟链接，这种虚拟链接称为会话（session）。会话层通过在数据流中设置检查点而保持应用程序之间的同步。允许应用程序进行通信的名称识别和安全性的工作就由会话层完成。

第六层，表示层。
定义由应用程序用来交换数据的格式。在这种意义上，表示层也称为转换器（translator）。该层负责协议转换、数据编码和数据压缩。转发程序在该层进行服务操作。

第七层，应用层，该层是OSI模型的最高层。应用层向应用进程展示所有的网络服务。当一个应用进程访问网络时，通过该层执行所有的动作。
纵观七层，从低级到高级。作一个形象的比喻就是从汇编到了BASIC，越到高层与硬件的关联就越弱。
所谓的网络七层协议就是OSI模型，具体分为：应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。
7——应用层
6——表示层
5——会话层
4——传输层
3——网络层
2——数据链路层
1——物理层

105.mysql数据库分库和分表

1，主从复制，读写分离

对主库修改数据，查询使用从库。一主多从，来降低数据库读取压力。

2，分库分表

根据实体业务来分库，分表。如，根据数据的活跃性，根据用户uid等。

3，mysql 不同存储引擎区别

InnoDB 用于数据完整性/写性能要求比较高的应用. MyISAM 适合查询应用。



分表是分散数据库压力的好方法。

分表，最直白的意思，就是将一个表结构分为多个表，然后，可以再同一个库里，也可以放到不同的库。

当然，首先要知道什么情况下，才需要分表。个人觉得单表记录条数达到百万到千万级别时就要使用分表了。

1，分表的分类

1>纵向分表

将本来可以在同一个表的内容，人为划分为多个表。（所谓的本来，是指按照关系型数据库的第三范式要求，是应该在同一个表的。）

分表理由：根据数据的活跃度进行分离，（因为不同活跃的数据，处理方式是不同的）

案例：

对于一个博客系统，文章标题，作者，分类，创建时间等，是变化频率慢，查询次数多，而且最好有很好的实时性的数据，我们把它叫做冷数据。而博客的浏览量，回复数等，类似的统计信息，或者别的变化频率比较高的数据，我们把它叫做活跃数据。所以，在进行数据库结构设计的时候，就应该考虑分表，首先是纵向分表的处理。

这样纵向分表后：

首先存储引擎的使用不同，冷数据使用MyIsam 可以有更好的查询数据。活跃数据，可以使用Innodb ,可以有更好的更新速度。

其次，对冷数据进行更多的从库配置，因为更多的操作时查询，这样来加快查询速度。对热数据，可以相对有更多的主库的横向分表处理。

其实，对于一些特殊的活跃数据，也可以考虑使用memcache ,redis

之类的缓存，等累计到一定量再去更新数据库。或者mongodb 一类的nosql 数据库，这里只是举例，就先不说这个。

2>横向分表

字面意思，就可以看出来，是把大的表结构，横向切割为同样结构的不同表，如，用户信息表，user_1,user_2 等。表结构是完全一样，但是，根据某些特定的规则来划分的表，如根据用户ID来取模划分。

分表理由：根据数据量的规模来划分，保证单表的容量不会太大，从而来保证单表的查询等处理能力。

案例：同上面的例子，博客系统。当博客的量达到很大时候，就应该采取横向分割来降低每个单表的压力，来提升性能。例如博客的冷数据表，假如分为100个表，当同时有100万个用户在浏览时，如果是单表的话，会进行100万次请求，而现在分表后，就可能是每个表进行1万个数据的请求（因为，不可能绝对的平均，只是假设），这样压力就降低了很多很多。

106.分表后进行分页

要是整体的分页显示那就更简单了
1、每个表的记录数是已知的，应在每次发生变化时记录到目录表中
2、无论是否排序（如果排序只是表的次序不同）至多会 union 两个分表

如假定共3个分表，记录数分别为 90，120，80 总记录数为 290
设分页是每页显示40条，则 
第1页 表一的 1 到 40
第2页 表一的 41 到 80
第3页 表一的 81 到 90 + 表二的 1 到 30
第4页 表二的 31 到 70
第5页 表二的 71 到 110
第6页 表二的 111 到 120 + 表三的 1 到 30
.....
计算起来非常简单

107.JDK动态代理代理是基本的设计模式之一，它为你提供额外的或者不同的操作。JAVA动态代理比代理的思想更迈进了一步，在动态代理上所做的所有调用都会被重定向到单一的调用处理器上，它的工作是揭示调用的类型并且确定相应的对策，动态代理中，接口中声明的所有方法都被转移到一个集中的地方处理，也就是invoke()中。

定义目标接口：
public interface UserManager {
public void addUser(String name,String password);
public void findUser(String id);
}
目标接口的实现类：
public class UserManagerImpl implements UserManager{
public void addUser(String name, String password) {
System.out.println("name:"+name+" password:"+password);
}
public void findUser(String id) {
System.out.println("id:"+id);
}
}
动态代理对象类，实现InvocationHandler 接口：
public class DynamicProxy implements InvocationHandler {
// 目标对象
private UserManager userManager;
// 通过构造方法传入目标对象
public DynamicProxy(UserManager userManager) {
this.userManager = userManager;
}
//根据传入的目标返回一个代理对象
public Object newProxy(){
//第一个参数指定产生代理对象的类加载器，需要将其指定为和目标对象同一个类加载器
//第二个参数要实现和目标对象一样的接口，所以只需要拿到目标对象的实现接口
//第三个参数表明这些被拦截的方法在被拦截时需要执行哪个InvocationHandler的invoke方法
return Proxy.newProxyInstance(userManager.getClass().getClassLoader(),
userManager.getClass().getInterfaces(), this);
}

public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
Object result = null;
try {
//反射调用目标对象的方法
result = method.invoke(userManager, args);
check();
} catch (Exception e) {
e.printStackTrace();
}
return result;
}
public void check(){
System.out.println("通过代理执行该方法");
}
}
实现类：
public class Invocation {
public static void main(String[] args) {
DynamicProxy dp = new DynamicProxy(new UserManagerImpl());
UserManager user = (UserManager)dp.newProxy();

user.addUser("song", "123456");
user.findUser("1");
}
}
首先对InvocationHandler 类传入目标对象接口，只能对接口进行处理，通过目标接口返回动态代理的目标对象，此时是一个代理对象，当调用该代理对象的方法时，执行inovke()方法，实现动态代理。

JAVA动态代理内部实现

一　代理设计模式

代理模式为目标对象提供一种代理以控制对实际对象的访问。在某些情况下，一个客户不想或者不能直接引用另一个对象，而代理对象可以在客户端和目标对象之间起到中介的作用。

为了保持行为的一致性，代理类和实际委托类通常会实现相同的接口，所以在访问者看来两者没有丝毫的区别。

　代理模式类图　　

常见的代理有:
1) 远程代理(Remote proxy)：对一个位于不同的地址空间对象提供一个局域代表对象，如RMI中的stub。　
2) 虚拟代理(Virtual proxy)：根据需要将一个资源消耗很大或者比较复杂的对象，延迟加载，在真正需要的时候才创建。
3) 保护代理(Protect or Access Proxy)：控制对一个对象的访问权限。
4) 智能引用(Smart Reference Proxy)：提供比目标对象额外的服务和功能。

通过代理类这一中间层，能够有效控制对实际委托类对象的直接访问，也可以很好地隐藏和保护实际对，实施不同的控制策略，从而在设计上获得了更大的灵活性。

二　动态代理使用

JAVA动态代理机制以巧妙的方式实现了代理模式的设计理念。

动态代理类图

动态代理在代理ProxySubject和RealSubject之间增加了InvocationHandler，这是一种通信间接化， 增加了灵 性性，例如可以把这个中间层实现为一个框架Framework，直接通过xml文件等方式来调用RealSubject。

108.cookie和session的常见问题

 1）cookie机制和session机制的区别
　　具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。
　　同时我们也看到，由于在服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的，但实际上还有其他选择。

2）会话cookie和持久cookie的区别
如果不设置过期时间，则表示这个cookie生命周期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。这种生命期为浏览会话期的cookie被称为会话cookie。会话cookie一般不保存在硬盘上而是保存在内存里。
如果设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie依然有效直到超过设定的过期时间。
　　存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存的cookie，不同的浏览器有不同的处理方式。

3）session的机制
　　session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构(也可能就是使用散列表)来保存信息。
　　但程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否包含了一个session标识－称为session id,如果已经包含一个session id则说明以前已经为此客户创建过session，服务器就按照session id把这个session检索出来使用(如果检索不到，可能会新建一个，这种情况可能出现在服务端已经删除了该用户对应的session对象，但用户人为地在请求的URL后面附加上一个JSESSION的参数)。
　　如果客户请求不包含session id，则为此客户创建一个session并且生成一个与此session相关联的session id，这个session id将在本次响应中返回给客户端保存。

4）保存session id的几种方式
A．保存session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。
B．由于cookie可以被人为的禁止，必须有其它的机制以便在cookie被禁止时仍然能够把session id传递回服务器，经常采用的一种技术叫做URL重写，就是把session id附加在URL路径的后面，附加的方式也有两种，一种是作为URL路径的附加信息，另一种是作为查询字符串附加在URL后面。网络在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。
C．另一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。

5）session什么时候被创建
　　一个常见的错误是以为session在有客户端访问时就被创建，然而事实是直到某server端程序(如Servlet)调用HttpServletRequest.getSession(true)这样的语句时才会被创建。

6）session何时被删除
session在下列情况下被删除：
A．程序调用HttpSession.invalidate()
B．距离上一次收到客户端发送的session id时间间隔超过了session的最大有效时间
C．服务器进程被停止
　　再次注意关闭浏览器只会使存储在客户端浏览器内存中的session cookie失效，不会使服务器端的session对象失效。

7）getSession()/getSession(true)、getSession(false)的区别
getSession()/getSession(true)：当session存在时返回该session，否则新建一个session并返回该对象
getSession(false)：当session存在时返回该session，否则不会新建session，返回null

8）Cookie的过期和Session的超时有什么区别
　　会话的超时由服务器来维护，它不同于Cookie的失效日期。首先，会话一般基于驻留内存的cookie不是持续性的cookie，因而也就没有截至日期。即使截取到JSESSIONID cookie，并为它设定一个失效日期发送出去。浏览器会话和服务器会话也会截然不同。

9）session cookie和session对象的生命周期是一样的吗
　　当用户关闭了浏览器虽然session cookie已经消失，但session对象仍然保存在服务器端

10）是否只要关闭浏览器，session就消失了
　　程序一般都是在用户做log off的时候发个指令去删除session，然而浏览器从来不会主动在关闭之前通知服务器它将要被关闭，因此服务器根本不会有机会知道浏览器已经关闭。服务器会一直保留这个会话对象直到它处于非活动状态超过设定的间隔为止。
　　之所以会有这种错误的认识，是因为大部分session机制都使用会话cookie来保存session id，而关闭浏览器后这个session id就消失了，再次连接到服务器时也就无法找到原来的session。
　　如果服务器设置的cookie被保存到硬盘上，或者使用某种手段改写浏览器发出的HTTP请求报头，把原来的session id发送到服务器，则再次打开浏览器仍然能够找到原来的session。
　　恰恰是由于关闭浏览器不会导致session被删除，迫使服务器为session设置了一个失效时间，当距离客户上一次使用session的时间超过了这个失效时间时，服务器就可以认为客户端已经停止了活动，才会把session删除以节省存储空间。
　　由此我们可以得出如下结论：
　　关闭浏览器，只会是浏览器端内存里的session cookie消失，但不会使保存在服务器端的session对象消失，同样也不会使已经保存到硬盘上的持久化cookie消失。

11）打开两个浏览器窗口访问应用程序会使用同一个session还是不同的session
　　通常session cookie是不能跨窗口使用的，当你新开了一个浏览器窗口进入相同页面时，系统会赋予你一个新的session id，这样我们信息共享的目的就达不到了。
　　此时我们可以先把session id保存在persistent cookie中(通过设置session的最大有效时间)，然后在新窗口中读出来，就可以得到上一个窗口的session id了，这样通过session cookie和persistent cookie的结合我们就可以实现了跨窗口的会话跟踪。

109.Map遍历

使用Iterator遍历

Map map = new HashMap();

Iterator> entries = map.entrySet().iterator();

while (entries.hasNext()) {

    Map.Entry entry = entries.next();

    System.out.println("Key = " + entry.getKey() + ", Value = " + entry.getValue());

}

在for-each循环中使用entries来遍历

Map map = new HashMap();

for (Map.Entry entry : map.entrySet()) {

    System.out.println("Key = " + entry.getKey() + ", Value = " + entry.getValue());

}

110.tomcat 使用memcache 实现 session共享

下载 需要的jar 包
kryo-1.03.jar
minlog-1.2.jar
reflectasm-0.9.jar
asm-3.2.jar
kryo-serializers-0.8.jar
msm-kryo-serializer-1.3.6.jar
joda-time-1.1.jar
将 这些jar包 放入 %TOMCATHOME%/lib 下

然后修改 %TOMCATHOME%/conf/server.xml

unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">

memcachedNodes="n1:localhost:11211"
requestUriIgnorePattern=".*\.(png|gif|jpg|css|js)$"
sessionBackupAsync="false"
sessionBackupTimeout="100"
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
customConverter="de.javakaffee.web.msm.serializer.kryo.JodaDateTimeRegistration"
/>





OK 完工 如此一来，在不影响系统原有代码的情况下 实现了 多台tomcat 的session共享 ，使用memcache 还可以保证性能。

111.自动登录

采用shiro的rememberMe用于自动登录，rememberMe自动生成cookie默认时间是一年

112.hibernate 二级缓存的应用

hibernate session是一级缓存  sessionFactory是二级缓存

在这里特别要注意的是对放入缓存中的数据不能有第三方的应用对数据进行更改（其中也包括在自己程序中使用其他方式进行数据的修改，例如，JDBC），因为那样Hibernate将不会知道数据已经被修改，也就无法保证缓存中的数据与数据库中数据的一致性。

 默认用EHCache但是不支持集群，集群用OSCache

组件	Provider类	类型	集群	查询缓存
Hashtable	org.hibernate.cache.HashtableCacheProvider	内存	不支持	支持
EHCache	org.hibernate.cache.EhCacheProvider	内存，硬盘	不支持	支持
OSCache	org.hibernate.cache.OSCacheProvider	内存，硬盘	支持	支持
SwarmCache	org.hibernate.cache.SwarmCacheProvider	集群	支持	不支持
JBoss TreeCache	org.hibernate.cache.TreeCacheProvider	集群	支持	支持

 @Entity
 @Table
 @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
 public class User implements Serializable {
     private static final long serialVersionUID = -5121812640999313420L;
     private Integer id;
     private String name;

     ......
 }

 Session s1= HibernateSessionFactory.getCurrentSession();
 s1.beginTransaction();
 System.out.println("第一次查询User");
 Query q = s1.createQuery("from User");
 q.setCacheable(true);
 q.list();
 System.out.println("放进二级缓存");
 s1.getTransaction().commit();

 Session s2= HibernateSessionFactory.getCurrentSession();
 s2.beginTransaction();
 System.out.println("第二次查询User,将不会发出sql");
 Query q = s2.createQuery("from User");
 q.setCacheable(true);
 q.list();
 s2.getTransaction().commit();

 //如果配置文件打开了generate_statistics性能调解，可以得到二级缓存命中次数等数据
 Statistics s = HibernateSessionFactoryUtil.getSessionFactory().getStatistics();
 System.out.println(s);
 System.out.println("put:"+s.getSecondLevelCachePutCount());
 System.out.println("hit:"+s.getSecondLevelCacheHitCount());
 System.out.println("miss:"+s.getSecondLevelCacheMissCount());

113.JAVA中sleep()、wait()、yield()、join()方法浅析

Java线程退出最好自己实现，在运行状态中一直检验一个状态，如果这个状态为真，就一直运行，如果外界更改了这个状态变量，那么线程就停止运行。
1.sleep()方法
在指定时间内让当前正在执行的线程暂停执行，但不会释放“锁标志”。不推荐使用。sleep()使当前线程进入阻塞状态，在指定时间内不会执行。
2.wait()方法
在其他线程调用对象的notify或notifyAll方法前，导致当前线程等待。线程会释放掉它所占有的“锁标志”，从而使别的线程有机会抢占该锁。
当前线程必须拥有当前对象锁。如果当前线程不是此锁的拥有者，会抛出Illegal Monitor State Exception异常。
唤醒当前对象锁的等待线程使用notify或notifyAll方法，也必须拥有相同的对象锁，否则也会抛出Illegal Monitor State Exception异常。
waite() 和notify()必须在synchronized函数或synchronized　block中进行调用。如果在non-synchronized函数或non-synchronized　block中进行调用，虽然能编译通过，但在运行时会发生 Illegal Monitor State Exception的异常。
3.yield方法
暂停当前正在执行的线程对象。yield()只是使当前线程重新回到可执行状态，所以执行yield()的线程有可能在进入到可执行状态后马上又被执行。yield()只能使同优先级或更高优先级的线程有执行的机会。
4.join方法
等待该线程终止。等待调用join方法的线程结束，再继续执行。如：t.join();//主要用于等待t线程运行结束，若无此句，main则会执行完毕，导致结果不可预测。

114.单点登录

Shiro 1.2开始提供了Jasig CAS单点登录的支持

115.线程状态图

116.Java 重写Object类的常见方法

hashCode(),toString(),equals(),finalize(),clone()

117.JVM的逻辑内存模型

1、程序计数器

程序计数器（Program Counter Register）是一块较小的内存空间，它的作用可以看做是当前线程所执行的字节码的行号指示器。

2、Java 虚拟机栈

与程序计数器一样，Java 虚拟机栈（Java Virtual Machine Stacks）也是线程私有的，它的生命周期与线程相同。虚拟机栈描述的是Java 方法执行的内存模型：每个方法被执行的时候都会同时创建一个栈帧（Stack Frame ①）用于存储局部变量表、操作栈、动态链接、方法出口等信息。每一个方法被调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。

在Java 虚拟机规范中，对这个区域规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError 异常；如果虚拟机栈可以动态扩展

（当前大部分的Java 虚拟机都可动态扩展，只不过Java 虚拟机规范中也允许固定长度的虚拟机栈），当扩展时无法申请到足够的内存时会抛出OutOfMemoryError 异常。

3、本地方法栈

本地方法栈（Native Method Stacks）与虚拟机栈所发挥的作用是非常相似的，其区别不过是虚拟机栈为虚拟机执行Java 方法（也就是字节码）服务，而本地方法栈则是为虚拟

机使用到的Native 方法服务。虚拟机规范中对本地方法栈中的方法使用的语言、使用方式与数据结构并没有强制规定，因此具体的虚拟机可以自由实现它。甚至有的虚拟机（譬

如Sun HotSpot 虚拟机）直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError 和OutOfMemoryError异常。

4、Java 堆

对于大多数应用来说，Java 堆（Java Heap）是Java 虚拟机所管理的内存中最大的一块。

Java 堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。

Java 堆是垃圾收集器管理的主要区域，因此很多时候也被称做“GC 堆”（GarbageCollected Heap，幸好国内没翻译成“垃圾堆”）。如果从内存回收的角度看，由于现在

收集器基本都是采用的分代收集算法，所以Java 堆中还可以细分为：新生代和老年代；再细致一点的有Eden 空间、From Survivor 空间、To Survivor 空间等。

根据Java 虚拟机规范的规定，Java 堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘空间一样。在实现时，既可以实现成固定大小

的，也可以是可扩展的，不过当前主流的虚拟机都是按照可扩展来实现的（通过-Xmx和-Xms 控制）。如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出

OutOfMemoryError 异常。

5、方法区

方法区（Method Area）与Java 堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽

然Java 虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做Non-Heap（非堆），目的应该是与Java 堆区分开来。

对于习惯在HotSpot 虚拟机上开发和部署程序的开发者来说，很多人愿意把方法区称为“永久代”（Permanent Generation），本质上两者并不等价，仅仅是因为HotSpot 虚

拟机的设计团队选择把GC 分代收集扩展至方法区，或者说使用永久代来实现方法区而已。对于其他虚拟机（如BEA JRockit、IBM J9 等）来说是不存在永久代的概念的。即

使是HotSpot 虚拟机本身，根据官方发布的路线图信息，现在也有放弃永久代并“搬家”至Native Memory 来实现方法区的规划了。

根据Java 虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError 异常。

6、运行时常量池

运行时常量池（Runtime Constant Pool）是方法区的一部分。Class 文件中除了有类的版本、字段、方法、接口等描述等信息外，还有一项信息是常量池（Constant Pool

Table），用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。

7、直接内存

直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域，但是这部分内存也被频繁地使用，而且也可能导致

OutOfMemoryError 异常出现，所以我们放到这里一起讲解。在JDK 1.4 中新加入了NIO（New Input/Output）类，引入了一种基于通道（Channel）

与缓冲区（Buffer）的I/O 方式，它可以使用Native 函数库直接分配堆外内存，然后通过一个存储在Java 堆里面的DirectByteBuffer 对象作为这块内存的引用进行

操作。这样能在一些场景中显著提高性能，因为避免了在Java 堆和Native 堆中来回复制数据。

118.初始化一个对象，都运用到哪些运行期数据区。

在Java 语言中，对象访问是如何进行的？对象访问在Java 语言中无处不在，是最普通的程序行为，但即使是最简单的访问，也会却涉及Java 栈、Java 堆、方法区这三个最重要内存区

域之间的关联关系，如下面的这句代码：

Object obj = new Object();

假设这句代码出现在方法体中，那“Object obj”这部分的语义将会反映到Java 栈的本地变量表中，作为一个reference 类型数据出现。而“new Object()”这部分的语义

将会反映到Java 堆中，形成一块存储了Object 类型所有实例数据值（Instance Data，对象中各个实例字段的数据）的结构化内存，根据具体类型以及虚拟机实现的对象内存布

局（Object Memory Layout）的不同，这块内存的长度是不固定的。另外，在Java 堆中还必须包含能查找到此对象类型数据（如对象类型、父类、实现的接口、方法等）的地

址信息，这些类型数据则存储在方法区中。

119.Java 堆溢出的解决方案

Java 堆内存的OutOfMemoryError异常是实际应用中最常见的内存溢出异常情况。出现Java 堆内存溢出时，异常堆栈信息“java.lang.OutOfMemoryError”会跟着进一步提示“Java heap space”。

要解决这个区域的异常，一般的手段是首先通过内存映像分析工具（如EclipseMemory Analyzer）对dump 出来的堆转储快照进行分析，重点是确认内存中的对象是

否是必要的，也就是要先分清楚到底是出现了内存泄漏（Memory Leak）还是内存溢出（Memory Overflow）。图2-5 显示了使用Eclipse Memory Analyzer 打开的堆转储快照文件。

如果是内存泄漏，可进一步通过工具查看泄漏对象到GC Roots 的引用链。于是就能找到泄漏对象是通过怎样的路径与GC Roots 相关联并导致垃圾收集器无法自动回收

它们的。掌握了泄漏对象的类型信息，以及GC Roots 引用链的信息，就可以比较准确地定位出泄漏代码的位置。

如果不存在泄漏，换句话说就是内存中的对象确实都还必须存活着，那就应当检查虚拟机的堆参数（-Xmx 与-Xms），与机器物理内存对比看是否还可以调大，从代码上

检查是否存在某些对象生命周期过长、持有状态时间过长的情况，尝试减少程序运行期的内存消耗。

120.JVM堆模型

JVM堆（Heap）= 新生代（Young） + 旧生代（Tenured）

新生代（Young）= Eden区 + Survivor区

 

121.java堆机制的详解

http://blog.csdn.net/lzwglory/article/details/48830259

122.垃圾回收器总结

http://blog.csdn.net/lzwglory/article/details/48858313

http://blog.csdn.net/lzwglory/article/details/48858313

123.CMS执行流程和应用场景

http://blog.csdn.net/lzwglory/article/details/48858641

124.jvm垃圾回收器

1:新生代串行收集器：(默认收集器)

　　算法：复制算法

　　-XX:+UseSerialGC 指定使用新生代串行收集器和老年代串行收集器

　　优点：效率高，久经考验

　　缺点：串行，如果回收对象过多，或者堆过大，停顿时间会过长。

　　2:老年代串行收集器(cms收集器的备选)

　　算法：标记-压缩算法

　　-XX:+UseSerialGC:指定新生代串行收集器和老年代串行收集器

　　-XX:+UseParNewGc:新生代使用并行收集器和老年代使用串行收集器

　　-XX:+UseParallelGc:新生代使用并行回收收集器和老年代使用串行收集器

　　3:并行收集器

　　算法：复制算法

　　工作在新生代的垃圾收集器，简单的将串行回收器多线程化，策略和串行一样。也是独占式的。在多cpu环境下会比串行收集器好，停顿时间短。

　　-XX:+UseParNewGC:新生代使用并行收集器，老年代使用串行回收器

　　-XX:+UseConcMarkSweepGC:新生代使用并行收集器，老年代使用cms

　　线程数量：

　　-XX:ParallelGCThreads指定，一般最好与cpu数量相当。cpu小于8个时和cpu数量一样，cpu大于8个时 3+[(5*cpu/8)]

　　4:新生代并行回收收集器(Parallel Scavenge)

　　算法：复制算法

　　和并行收集器一样，区别在于这个收集器关注系统吞吐量

　　-XX:+UseParallelGC:新生代使用并行回收收集器，老年代使用串行收集器

　　-XX:+UseParallelOldGC:新生代和老年代都使用并行回收收集器

　　吞吐量设置：

　　-XX:MaxGCPauseMillis:设置停顿时间不超过多少。大于0的整数，收集器会调整对的大小或者其他一些参数，使得垃圾收集停顿时间控制在设置的时间

　　-XX:GCTimeRatio:设置吞吐量大小，0~100之间的整数 公式：1/(1+n)，系统将花费不超过这个时间来用于垃圾收集。

　　-XX:useAdaptiveSizePolicy:打开自适应gc策略，新生代大小，eden和servivor的比例，晋升老年代的对象年龄都会自动调整以达到对大小，吞吐量和停顿时间之间的平衡。

　　5:老年代并行回收收集器

　　算法：标记压缩算法

　　和新生代并行回收器一样，它也是一种关注吞吐量的收集器

　　-XX:+UseParallelOldGC:新生代和老年代都使用并行回收收集器

　　6:cms收集器

　　算法：标记-清除算法

　　和并行回收收集器的区别是：注重系统停顿时间

　　工作步骤：

　　初始标记：独占资源

　　并发标记：非独占资源

　　重新标记：独占资源

　　并发清除：非独占资源

　　并发重置：非独占资源

　　-XX:ParallelGCThreads:设置cms的线程数量，默认启动线程数是：(ParallelGCThreads+3/4)

　　-XX:CMSInitiatingOccupancyFraction:设置当老年代空间实用率达到百分比值时进行一次cms回收

　　因为使用标记清除算法，所以长时间后会有碎片产生

　　-XX:+UseCMSCompactAtFullCollection:设置cms在垃圾收集完成后进行一次内存碎片整理

　　-XX:CMSFullGCsBeforeCompaction:设定进行多少次cms回收后，进行一次内存压缩。

　　应为cms不停止应用程序，所以在cms回收过程中，可能因为内存不足而导致回收失败，失败的话会启动老年代串行收集器进行垃圾回收，这样应用程序将完全中断，这时停顿时间可能会很长。可以通过设置-XX:CMSInitiatingOccupancyFraction来解决

　　7:G1收集器(garbage first) jdk1.6update14才提供预览版，jdk1.7才发布

　　总结：

　　在众多的垃圾回收器中，没有最好的，只有最适合应用的回收器，根据应用软件的特性以及硬件平台的特点，选择不同的垃圾回收器，才能有效的提高系统性能。

125.jvm调优思路与方法：

1:将新对象预留在新生代

　　一般来说，当survivor区空间不够，或者占用量达到50%时，就会将对象进入老年代(不管对象年龄有多大)

　　2:大对象进入老年代

　　开发中要避免短命的大对象，目前没有特别好的方法回收短命大对象，大对象最好直接进入老年区，因为大对象在新生区，占用空间大，会由于空间不足而导致很多小对象进入到老年区。

　　-XX:PretenureSizeThreshold:设置大对象直接进入老年代的阈值，当对象的大小超过这个值将直接分配在老年代

3:设置对象进入老年代 的年龄：

　　-XX:MaxTenuringThreshold:设置对象进入老年代的年龄，默认值时15,但是如果空间不够，还是会将对象移到老年代。

　　4:稳定与震荡的堆大小

　　稳定的堆大小能减少gc次数，但是每次gc时间增加

　　震荡的堆大小能增加gc次数，但是每次gc时间减少

　　-XX:MinHeapFreeRatio:最小空闲比例，当堆空间空闲内存小于这个比例，则扩展

　　-XX:ManHeapFreeRatio:最大空闲比例，当堆空间空闲内存大于这个比例，则压缩

　　-Xms和-Xmx相等时，上面的参数失效

　　5:吞吐量方案：

　　4G内存32核吞吐量优先方案：尽可能减少系统的执行垃圾回收的总时间，考虑使用关注吞吐量的并行回收收集器。

　　-Xms:3800

　　-Xmx:3800

　　-Xss:128k //减少线程栈大小，使剩余系统内存支持更多线程

　　-Xmn:2g //设置新生代大小

　　-XX:UseParallelGC:新生代并行回收收集器

　　-XX:ParallelGCTHreads:设置线程数

　　-XX:+UseParallelOldGC:老年代也使用并行回收收集器

　　6:使用大页案例

　　-Xmx:2506

　　-Xms:2506

　　-Xss:128k //减少线程栈大小，使剩余系统内存支持更多线程

　　-XX:UseParallelGC:新生代并行回收收集器

　　-XX:ParallelGCTHreads:20

　　-XX:+UseParallelOldGC:老年代也使用并行回收收集器

　　-XX:LargePageSizeInBytes=256m

　　7:降低停顿案例：

　　降低停顿首先考虑的是使用关注系统停顿的cms回收器，其次为了减少fullgc次数，应尽可能将对象预留在新生代，因为新生代minorgc的成本远小于老年代的fullgc

　　-Xms:3550

　　-Xmx:3550

　　-Xss:128k //减少线程栈大小，使剩余系统内存支持更多线程

　　-Xmn:2g //设置新生代大小

　　-XX:ParallelGCThreads:20

　　-XX:+UseConcMarkSweepGC //老年代使用cms回收器

　　-XX:+UseParNewGC //新生代使用并行回收器

　　-XX:SurvivorRatio=8 //设置eden和survivor比例为8:1

　　-XX:TargetSurvivorRatio=90 //设置survivor使用率

　　-XX:MaxTenuringThreshold=31 //年轻对象进入老年代的年龄，默认是15,这里是31