面试
1、jvm性能调优都做了什么
-
控制GC的行为.GC是一个后台处理,但是它也是会消耗系统性能的,因此经常会根据系统运行的程序的特性来更改GC行为
-
控制JVM堆栈大小.一般来说,JVM在内存分配上不需要你修改,(举例)但是当你的程序新生代对象在某个时间段产生的比较多的时候,就需要控制新生代的堆大小.同时,还要需要控制总的JVM大小避免内存溢出
-
控制JVM线程的内存分配.如果是多线程程序,产生线程和线程运行所消耗的内存也是可以控制的,需要通过一定时间的观测后,配置最优结果
2、高并发情况下，我们系统是如何支撑大量的请求的
1、HTML静态化
其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最 有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的 新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管 理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。
2、图片服务器分离
大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型 网站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为 图片问题而崩溃，在应用服务器和图片服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持，尽可能少的 LoadModule，保证更高的系统消耗和执行效率。 这一实现起来是比较容易的一现，如果服务器集群操作起来更方便，如果是独立的服务器，新手可能出现上传图片只能在服务器本地的情况下，可以在令一台服务器 设置的IIS采用网络路径来实现图片服务器，即不用改变程序，又能提高性能，但对于服务器本身的IO处理性能是没有任何的改变。
3、数据库集群和库表散列
大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。
在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。
上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且 最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功 能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架 构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统 随时增加一台低成本的数据库进来补充系统性能。
4、缓存
缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。
架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。
网站程序开发方面的缓存，Linux上提供的Memory Cache是常用的缓存接口，可以在web开发中使用，比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享，一些大型社区使用了这样的架构。在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块，Java就更多了，.net不是很熟悉，相信也肯定有。
5、镜像
镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和 EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现 成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。
6、负载均衡
负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。
硬件四层交换
第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。 第四层交换功能就像是 虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂 的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决 定。
在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。
软件四层交换
了解了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。
软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满 足多种应用需求，这对于分布式的系统来说必不可少。
一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。这样的架构我准备空了专门详细整理一下和大家探讨。
对于大型网站来说，前面提到的每个方法可能都会被同时使用到，我这里介绍得比较浅显，具体实现过程中很多细节还需要大家慢慢熟悉和体会，有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大
3、集群如何同步会话状态
在集群中session安全和同步是个最大的问题，下面是收集到的几种session同步的方案，希望能通过分析其各自的优劣找出其适应的场景。
1. 客户端cookie加密
简单，高效。比较好的方法是自己采用cookie机制来实现一个session,在应用中使用此session实现。
问题：session中数据不能太多，最好只有个用户id。
参考实现：http://rollerweblogger.org/
2. application server的session复制
可能大部分应用服务器都提供了session复制的功能来实现集群，tomcat,jboss,was都提供了这样的功能。
问题：
性能随着服务器增加急剧下降，而且容易引起广播风暴；
session数据需要序列化，影响性能。
如何序列化，可以参考 对象的序列化和反序列化.
参考资料:
3. 使用数据库保存session
使用数据库来保存session,就算服务器宕机了也没事，session照样在。
问题：
程序需要定制；
每次请求都进行数据库读写开销不小(使用内存数据库可以提高性能，宕机就会丢失数据。可供选择的内存数据库有BerkeleyDB,Mysql的内存表);
数据库是一个单点，当然可以做数据库的ha来解决这个问题。
4. 使用共享存储来保存session
和数据库类似,就算服务器宕机了也没事，session照样在。使用nfs或windows文件共享都可以,或者专用的共享存储设备。
问题：
程序需要定制；
频繁的进行数据的序列化和反序列化，性能是否有影响；
共享存储是一个单点，这个可以通过raid来解决。
5. 使用memcached来保存session
这种方式跟数据库类似，不过因为是内存存取的，性能自然要比数据库好多了。
问题：
程序需要定制,增加了工作量；
存入memcached中的数据都需要序列化，效率较低；
memcached服务器一死，所有session全丢。memchached能不能做HA? 我也不知道，网站上没提。
参考资料:
6. 使用terracotta来保存session
跟memcached类似，但是数据不需要序列化，并且是Find-Grained Changes，性能更好。配置对原来的应用完全透明，原有程序几乎不用做任何修改。而且terracotta本身支持HA。
问题：terracotta的HA本身进行数据复制性能如何？
参考资料：
使用Terracotta和Tomcat建立ACTIVE-PASSIVE模式的集群
4、负载均衡的原理
网络负载平衡使用两台或更多台一起工作的主机计算机组成的群集，为服务器提供了高可用性和高伸缩性。Internet 客户端使用一个 IP 地址或一组地址访问群集。客户端无法区别群集和单一服务器。服务器应用程序并不表明它们是在群集上运行的。但是，网络负载平衡群集与运行单个服务器应用程序的单个主机有很大的区别，因为即使在某个群集主机发生故障的情况下，它也可以提供不间断服务。群集对客户端请求的响应也比单个主机快。
如果某个主机发生故障或脱机，则网络负载平衡通过将传入的网络通信重定向到工作的群集主机，从而带来了高可用性。连到脱机主机的现有连接将丢失，但是 Internet 服务仍然是可用的。在多数情况下（例如，就 Web 服务器而言），客户端软件可以自动重试失败的连接，而且客户端在接收响应时，只有数秒钟的延迟。
网络负载平衡通过在分配给网络负载平衡群集的一个或多个虚拟 IP 地址（群集 IP 地址）间分配传入的网络通信，从而带来了可变化的性能。然后，群集中的主机同时对不同的客户端请求甚至来自同一客户端的多个请求做出响应。例如，Web 浏览器可以从网络负载平衡群集中的不同主机获得所有单张网页中的多幅图像。这就提高了处理速度，并缩短了对
5、数据库事务属性
原子性
一致性
隔离性
持久性
6、二叉树的遍历算法
7、hashtable和hashmap的区别
Hashtable和HashMap类有三个重要的不同之处。第一个不同主要是历史原因。Hashtable是基于陈旧的Dictionary类的，HashMap是Java 1.2引进的Map接口的一个实现。
也许最重要的不同是Hashtable的方法是同步的，而HashMap的方法不是。这就意味着，虽然你可以不用采取任何特殊的行为就可以在一个多线程的应用程序中用一个Hashtable，但你必须同样地为一个HashMap提供外同步。一个方便的方法就是利用Collections类的静态的synchronizedMap()方法，它创建一个线程安全的Map对象，并把它作为一个封装的对象来返回。这个对象的方法可以让你同步访问潜在的HashMap。这么做的结果就是当你不需要同步时，你不能切断Hashtable中的同步（比如在一个单线程的应用程序中），而且同步增加了很多处理费用。
第三点不同是，只有HashMap可以让你将空值作为一个表的条目的key或value。HashMap中只有一条记录可以是一个空的key，但任意数量的条目可以是空的value。这就是说，如果在表中没有发现搜索键，或者如果发现了搜索键，但它是一个空的值，那么get()将返回null。如果有必要，用containKey()方法来区别这两种情况。
一些资料建议，当需要同步时，用Hashtable，反之用HashMap。但是，因为在需要时，HashMap可以被同步，HashMap的功能比Hashtable的功能更多，而且它不是基于一个陈旧的类的，所以有人认为，在各种情况下，HashMap都优先于Hashtable。
关于Properties
有时侯，你可能想用一个hashtable来映射key的字符串到value的字符串。DOS、Windows和Unix中的环境字符串就有一些例子，如key的字符串PATH被映射到value的字符串C:\WINDOWS;C:\WINDOWS\SYSTEM。Hashtables是表示这些的一个简单的方法，但Java提供了另外一种方法。
Java.util.Properties类是Hashtable的一个子类，设计用于String keys和values。Properties对象的用法同Hashtable的用法相象，但是类增加了两个节省时间的方法，你应该知道。
Store()方法把一个Properties对象的内容以一种可读的形式保存到一个文件中。Load()方法正好相反，用来读取文件，并设定Properties对象来包含keys和values。
注意，因为Properties扩展了Hashtable，你可以用超类的put()方法来添加不是String对象的keys和values。这是不可取的。另外，如果你将store()用于一个不包含String对象的Properties对象，store()将失败。作为put()和get()的替代，你应该用setProperty()和getProperty()，它们用String参数。
好了，我希望你现在可以知道如何用hashtables来加速你的处理了。
8、并发、同步的接口或方法
9、string、stringbuilder、stringbuffer区别
1. 在执行速度方面的比较：StringBuilder > StringBuffer
2. StringBuffer与StringBuilder，他们是字符串变量，是可改变的对象，每当我们用它们对字符串做操作时，实际上是在一个对象上操作的，不像String一样创建一些对象进行操作，所以速度就快了。
3. StringBuilder：线程非安全的
StringBuffer：线程安全的
当我们在字符串缓冲去被多个线程使用是，JVM不能保证StringBuilder的操作是安全的，虽然他的速度最快，但是可以保证StringBuffer是可以正确操作的。当然大多数情况下就是我们是在单线程下进行的操作，所以大多数情况下是建议用StringBuilder而不用StringBuffer的，就是速度的原因。
对于三者使用的总结：1.如果要操作少量的数据用 = String
2.单线程操作字符串缓冲区 下操作大量数据 = StringBuilder
3.多线程操作字符串缓冲区 下操作大量数据 = StringBuffer
10、https处理的一个过程，对称加密和非对称加密
加密算法
加密算法有很多种，区别和衡量他们的方法就是看他们是否容易被破解的程度和加密的速度如下图可见AES 是最快的强加密算法
当然有更快或比较慢的算法了，他们都有用处。如果你只是加密一段信息，也不是经常需要，那你可以用最强的加密算法，甚至也可以用不同的算法加密两次。如果想要加密速度快点，那就用AES.
加密类型
之前说过的加密算法绝大部分都属于以下两种加密类型之一：
对称加密：加密解密用的是同样的“钥匙”
非对称加密：加密解密用的是不同的“钥匙”
对称加密
用邮局的例子来解释下对称加密
Alice 在盒子里放有信息，盒子上有挂锁，她有钥匙。通过邮局她把这个盒子寄给Bob。Bob收到盒子后，用相同的钥匙打开盒子(钥匙之前就得到了，可能是Alice面对面给他的)。然后Bob可以用同样的方法回复。
对称加密可以分为两种：一种是一个一个加密信息，另一种是分块加密信息，通常分为64位加密为一块。块Twofish, Serpent, AES (Rijndael), Blowfish, CAST5, RC4, TDES, and IDEA.
非对称加密
Bob和Alice各有自己的盒子。Alice要跟Bob秘密通信，她先让Bob把开着的盒子通过邮局发给她。Alice拿到盒子后放入信息锁上，然后发给Bob。Bob就可以用他自己的钥匙打开了。回复的话就用同样的方法。
此法最大的好处是你不必得到对方的“钥匙”，以防别人在钥匙发送过程中偷偷复制钥匙，进而窃取信息。而且就算Bob的钥匙被窃取复制了，Alice跟别人的通信也是安全的，因为Alice用的是别人的钥匙。
非对称算法在加密和解密时用的是不同的钥匙。信息接受者有两把钥匙：一把“公匙”，一把“私匙”。公匙是给信息发送者用来加密的，私匙是自己用来解 密的这样最大的好处是：不必通过不安全的渠道发送私密的东西。公匙本来就是给别人用的，不用藏好。你的私匙在你产生私匙的电脑里保存着。
网站如何通过加密和用户安全通信
SSL (Secure Sockets Layer) 是用来保障你的浏览器和网站服务器之间安全通信，免受网络“中间人”窃取信息。SSL原理很简单。当你的浏览器向服务器请求一个安全的网页(通常是 https://)
服务器就把它的证书和公匙发回来
浏览器检查证书是不是由可以信赖的机构颁发的，确认证书有效和此证书是此网站的。
使用公钥加密了一个随机对称密钥，包括加密的URL一起发送到服务器
服务器用自己的私匙解密了你发送的钥匙。然后用这把对称加密的钥匙给你请求的URL链接解密。
服务器用你发的对称钥匙给你请求的网页加密。你也有相同的钥匙就可以解密发回来的网页了
11、线程的几种状态
1.新建状态(New)：
当用new操作符创建一个线程时， 例如new Thread(r)，线程还没有开始运行，此时线程处在新建状态。 当一个线程处于新生状态时，程序还没有开始运行线程中的代码
2.就绪状态(Runnable)
一个新创建的线程并不自动开始运行，要执行线程，必须调用线程的start()方法。当线程对象调用start()方法即启动了线程，start()方法创建线程运行的系统资源，并调度线程运行run()方法。当start()方法返回后，线程就处于就绪状态。
处于就绪状态的线程并不一定立即运行run()方法，线程还必须同其他线程竞争CPU时间，只有获得CPU时间才可以运行线程。因为在单CPU的计算机系统中，不可能同时运行多个线程，一个时刻仅有一个线程处于运行状态。因此此时可能有多个线程处于就绪状态。对多个处于就绪状态的线程是由Java运行时系统的线程调度程序(thread
scheduler)来调度的。
3.运行状态(Running)
当线程获得CPU时间后，它才进入运行状态，真正开始执行run()方法.
4. 阻塞状态(Blocked)
线程运行过程中，可能由于各种原因进入阻塞状态:
1>线程通过调用sleep方法进入睡眠状态；
2>线程调用一个在I/O上被阻塞的操作，即该操作在输入输出操作完成之前不会返回到它的调用者；
3>线程试图得到一个锁，而该锁正被其他线程持有；
4>线程在等待某个触发条件；
......
所谓阻塞状态是正在运行的线程没有运行结束，暂时让出CPU，这时其他处于就绪状态的线程就可以获得CPU时间，进入运行状态。
5. 死亡状态(Dead)
有两个原因会导致线程死亡：
1) run方法正常退出而自然死亡，
2) 一个未捕获的异常终止了run方法而使线程猝死。
为了确定线程在当前是否存活着（就是要么是可运行的，要么是被阻塞了），需要使用isAlive方法。如果是可运行或被阻塞，这个方法返回true； 如果线程仍旧是new状态且不是可运行的， 或者线程死亡了，则返回false.
