**面试高频问题知识点总结**
Java集合类里面基本的接口有哪些？
我们能否让HashMap线程同步？
你知道HashMap的工作原理吗？你知道HashMap的get()方法的工作原理吗？
当两个对象的hashcode相同会发生什么？
接口是否可继承接口?抽象类是否可实现(implements)接口?抽象类是否可继承具体类(concreteclass)?抽象类中是否可以有静态的main方法？
Java中实现多态的机制是什么？
什么是java序列化，如何实现java序列化？或者请解释Serializable接口的作用。
Java子父类间静态代码块、构造代码块、构造方法的执行顺序
运行时异常与一般异常有何异同？
简单说说Java中的异常处理机制的简单原理和应用。
Java 中堆和栈有什么区别？
描述一下JVM加载class文件的原理机制?
Jvm怎么判断对象可以回收了？
GC是什么?为什么要有GC?
垃圾回收的优点和原理。并考虑2种回收机制。
垃圾回收器的基本原理是什么？垃圾回收器可以马上回收内存吗？有什么办法主动通知虚拟机进行垃圾回收？
5，出现异常，回滚 ），利用浏览器访问该根域名下的所有二级域名站点时，会传递与之域名对应的所有Cookie内容的特性，从而实现用户的 Cookie化Session 在多服务间的共享访问。
这 个方案的优点无需额外的服务器资源；缺点是由于受http协议头信心长度的限制，仅能够存储小部分的用户信息，同时Cookie化的 Session内容需要进行安全加解密（如：采用DES、RSA等进行明文加解密；再由MD5、SHA-1等算法进行防伪认证），另外它也会占用一定的带 宽资源，因为浏览器会在请求当前域名下任何资源时将本地Cookie附加在http头中传递到服务器。
增大内存(堆，持久代)并开启server模式
我在做XXX项目时,用到了poi导入和导出数据,由于公司的业务比较繁多,数据量很大,测试时报内存溢出,经过我的分析再结合上网查阅资料,发现可能是tomcat内存不足,需要增大,修改配置文件后测试不再报错.
tomcat增大内存的方式通过修改tomcat配置文件
都是典型的函数式接口。
解,这个注解是非必须的，只要接口符合函数式接口的标准（即只包含一个方法的接口），虚拟机会自
动判断，但 最好在接口上使用注解==@FunctionalInterface==进行声明，以免团队的其他人员错误地
往接口中添加新的方法。
1.一个括号内用逗号分隔的形式参数，参数是函数式接口里面方法的参数
3.方法体，可以是表达式和代码块，方法体函数式接口里面方法的实现，如果是代码块，则必须用{}
来包裹起来，且需要一个return 返回值，但有个例外，若函数式接口里面方法返回值是void，则无
lambda表达式语法代码简洁，能简化集合上数据的多线程或者多核的处理，提供更快的集合处理速度
session是存储在服务器端，cookie是存储在客户端的，所以安全来讲session的安全性要比cookie
高，然后我们获取session里的信息是通过存放在会话cookie里的sessionid获取的。又由于
session是存放在服务器的内存中，所以session里的东西不断增加会造成服务器的负担，所以会把很
重要的信息存储在session中，而把一些次要东西存储在客户端的cookie里，然后cookie确切的说分
为两大类分为会话cookie和持久化cookie，会话cookie确切的说是存放在客户端浏览器的内存中，所
以说他的生命周期和浏览器是一致的，浏览器关了会话cookie也就消失了，然而持久化cookie是存放
在客户端硬盘中，而持久化cookie的生命周期就是我们在设置cookie时候设置的那个保存时间，然后
我们考虑一问题当浏览器关闭时session会不会丢失，从上面叙述分析session的信息是通过
失所以我们的sessionid也就消失了，但是session的信息还存在服务器端，这时我们只是查不到所谓
的session但它并不是不存在。那么，session在什么情况下丢失，就是在服务器关闭的时候，或者是
sessio过期，再或者调用了invalidate()的或者是我们想要session中的某一条数据消失调用
微信扫描支付的实现话术
大型网站在架构上应当考虑哪些问题？
- 分层：分层是处理任何复杂系统最常见的手段之一，将系统横向切分成若干个层面，每个层面只承担单一的职
责，然后通过下层为上层提供的基础设施和服务以及上层对下层的调用来形成一个完整的复杂的系统。计算机网
络的开放系统互联参考模型（OSI/RM）和Internet的TCP/IP模型都是分层结构，大型网站的软件系统也可以
使用分层的理念将其分为持久层（提供数据存储和访问服务）、业务层（处理业务逻辑，系统中最核心的部分）
和表示层（系统交互、视图展示）。需要指出的是：（1）分层是逻辑上的划分，在物理上可以位于同一设备上
也可以在不同的设备上部署不同的功能模块，这样可以使用更多的计算资源来应对用户的并发访问；（2）层与
层之间应当有清晰的边界，这样分层才有意义，才更利于软件的开发和维护。
- 分割：分割是对软件的纵向切分。我们可以将大型网站的不同功能和服务分割开，形成高内聚低耦合的功能模
块（单元）。在设计初期可以做一个粗粒度的分割，将网站分割为若干个功能模块，后期还可以进一步对每个模
块进行细粒度的分割，这样一方面有助于软件的开发和维护，另一方面有助于分布式的部署，提供网站的并发处
- 分布式：除了上面提到的内容，网站的静态资源（JavaScript、CSS、图片等）也可以采用独立分布式部署
并采用独立的域名，这样可以减轻应用服务器的负载压力，也使得浏览器对资源的加载更快。数据的存取也应该
是分布式的，传统的商业级关系型数据库产品基本上都支持分布式部署，而新生的NoSQL产品几乎都是分布式
的。当然，网站后台的业务处理也要使用分布式技术，例如查询索引的构建、数据分析等，这些业务计算规模庞
大，可以使用Hadoop以及MapReduce分布式计算框架来处理。
- 集群：集群使得有更多的服务器提供相同的服务，可以更好的提供对并发的支持。
- 缓存：所谓缓存就是用空间换取时间的技术，将数据尽可能放在距离计算最近的位置。使用缓存是网站优化的
第一定律。我们通常说的CDN、反向代理、热点数据都是对缓存技术的使用。
- 异步：异步是实现软件实体之间解耦合的又一重要手段。异步架构是典型的生产者消费者模式，二者之间没有
直接的调用关系，只要保持数据结构不变，彼此功能实现可以随意变化而不互相影响，这对网站的扩展非常有
利。使用异步处理还可以提高系统可用性，加快网站的响应速度（用Ajax加载数据就是一种异步技术），同时
还可以起到削峰作用（应对瞬时高并发）。"；能推迟处理的都要推迟处理"是网站优化的第二定律，而异步是践行网站优化第二定律的重要手段。
- 冗余：各种服务器都要提供相应的冗余服务器以便在某台或某些服务器宕机时还能保证网站可以正常工作，同
时也提供了灾难恢复的可能性。冗余是网站高可用性的重要保证。
我们在使用FastDFS部署一个分布式文件系统的时候，通过FastDFS的客户
端API来进行文件的上传、下载、删除等操作。同时通过FastDFS的HTTP
服务器来提供HTTP服务。但是FastDFS的HTTP服务较为简单，无法提供负
载均衡等高性能的服务，所以FastDFS的开发者——淘宝的架构师余庆同
学，为我们提供了Nginx上使用的FastDFS模块（也可以叫FastDFS的
Nginx模块）。其使用非常简单。
- 首先拿公司资质去支付宝申请商铺号和秘钥，成功后支付宝会给你返回一个API，里面有商铺号、秘钥、支
付的URL、回调的URL格式、传递参数的规格等。
- 点击“支付”，会跳进自己写的一个action方法中，从页面传过去的有订单号和价格总和，再把商铺号、秘
钥、回调的URL一起add到一个list里。
- 用httpclient把list根据支付宝给的支付URL传递给支付宝。
- 此时支付宝会把你传递过来的商铺号和秘钥进行比对，如果成功，支付宝会以html的方式返回一个选择银行
支付的界面。你进行支付就OK。
- 你支付完成后，支付宝会把流水号、订单号、价格返回，此时你action的回调方法里会把这些数据进行比
对，都正确后给支付宝发送一个“SUCCESS”，支付宝就知道支付已经成功，页面就跳转到支付成功页面。反之
就跳转到支付失败页面（这里所有支付宝返回给我们的页面都是支付宝自己的页面，我们不需要写）
- 最后把流水号等相关数据拿去数据库进行一个操作。我们是订单表和购物车表为一张表，此时只需要把订单
状态从0（购物车）改为1（付款后的订单），然后再把流水号存入。此时整个支付就完成了。
流水号主要负责的是商城数据库的价格与第三方支付方价格进行对比！！成功则审核通过并发货！
return_url只是告诉你支付宝已经接受到了请求但支付请求还不一定执行结束（即时到账一般情况下这个也已
notify_url是支付宝已经处理请求之后，这时候整比交易都已经完成，一般是用这个来更新数据
用户支付成功，商户没有收到支付结果的通知问题？
用户在我们的支付成功，支付成功一定收到支付宝的通知。在这个通知之前
是会回调我们提供的接口。支付宝回调的过程中，没有调通我们的支付接口。
【支付平台不健壮，就是服务不稳定导致的】
用户马上投诉，解决办法，客服后台，根据用户提供的订单，查询支付的信息（这个查询我们是直接调用支付报
接口提供的查询功能进行查询的，如果存在的话就是我们网站的问题，这我们的代码会修改订单的状态）。
当然我们还有一个对账系统，这个对账体统只要做的是，将我们支付平台的订单到第三方支付进行查询，看是
参数信息 （秘钥）— > 根据加密的算法进行加密 -->生成加密的签名 ---->进行
传递 —> 我会根据秘钥+传过来的参数，在进行一次加密 也会生成一个签名 ，传过来的签名和我
自己生成的签名进行对比，如果一直说明数据没有修改，如果不一致，说明数据修改了。
我们网站目前支持支付宝支付和微信支付 。
其实所有的第三方支付都是差不多的，就根据他的文档直接写代码实现
自己的业务逻辑就可以了，它的接口是什么要什么样的数据。我们就给他什
么样的数据，支付成功后会跳转到我们的回调接口。（像支付宝有同步和异
步的回调，微信配置一个回调的授权域名）
因为我们的网站考虑到后期可能还会对接其他的支付，减轻对接的麻
烦，所以我们对外提供了一个公共的方法，根据传过来的值（paytype），
进行路由判断，找到对应的支付方式，比如路由到支付宝的默认支付，那就
走支付宝的默认支付代码。
我们网站目前对接的是支付宝，微信，
redis应用场景话术
在我做的项目里面,我将一些热数据存放到Redis缓存里面,这样可以减轻数据库的压力,加快用户的访问速度,
使用户对我们的产品提升好感.
我在之前的公司做过一个电商项目,这个电商项目,我们将Redis技术用到了商品这一模块,我们将用户查看的商
品放入redis缓存中,等用户下次访问就会比第一次访问的速度更快,当然这样也会出现问题,会给redis缓存增
加压力,数据会越来越多,这一问题我们是这样的解决的,当用户点击某一个商品,我们将这一个商品放入redis
缓存中,在放入缓存中我们给这件商品设置一个过期时间,当这件商品或者某一件商品达到了我们设置的这个过期
时间的时候,就将它从redis缓存中删除,这样就不会使那些点击次数少的数据一直存放在redis缓存中.
其他的还有首页里面一些不经常变动的数据我也会将它放入redis缓存里
webservice是SOA（面向服务编程）的一种实现，
主要是用来实现异构平台通信也就
是不同平台不同项目之间的数据传输，从而避免了信息孤岛的问题，
进行异构平台通信是因为它是完全基于xml的，
跨语言，跨框架的，在java中通常有三种技术框架分别是xfire,cxf,axis2。
WS-Security标准的安全验证(使用回调函数)。
用来描述发布的接口（服务） webservice的具体三种实现方式（框架）或者三种实现框架的区别 1. Axis2:可以用多种语言开发， 是一个重量级框架，功能非常强大， 2. Xfire：它相比Axis2来说是一个轻量级框架， 它的性能要比Axis2高。 3. cxf：是Xfire的升级版，就好比是， 然后cxf和spring集成起来非常方便，简易， 性能方面也要比Xfire高。
我在以前做项目的时候，其中遇到一个功能，
需要进行两个项目之间的数据的传输，
项目经理让我去完成这个任务，我根据以往的项目经验，
想到两种解决方案，第一种
就是开放另外一个项目的数据库的权限给我，
然后我直接通过访问另外一个项目的数据
库，来得到需要的信息，但后来我分析了下，觉的这种方式不安全，
这个项目是另外一家公司负责在做，所以数据库里面的表结构，
到的责任问题都很多，所以我就采用了第二种方案，
异构系统之间数据信息的传递，webservices的具体实现，
我根据以往的项目经验，了解到cxf是xfire的升级版本，适用于java语言，
而axis2支持更多的语言，
性能相对于cxf要低，通过上面分析，
结合我们目前的两个项目都是基于java
语言的，所以我采用cxf这种方式实现了两个项目之间数据的传递，
webservice的安全性我们采用了基于
生成客户端调用的中间桥梁java类，
将生成的java类拷贝到客户端项目中，
通过serviceClass指明充当中间桥梁的服务类，之后获取该bean,
就可以通过它来访问发布的webservice接口中的方法。
- 使用c和c++编写，并使用了多种编译器进行测试，保证源代码的可移植性
- 为多种编程语言提供可API
- 支持多线程，充分利用CPU资源
优化的SQL查询算法，有效的提高查询速度
- 提供多语言支持，常见的编码如：GB2312、BIG5、UTF8提供用于管理、检查、优化数据库操作的管理工具
- 大型的数据库。可以处理拥有上千万条记录的大型数据库
- MySQL软件采用了双授权政策，分为社区版和商业版，由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，一般中小型网站的开发都选择MySQL作为网站数据库
- MySQL使用标准的SQL数据语言形式
- Mysql是可以定制的，采用GPL协议，你可以修改源码来开发自己的MySQL系统
- Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
- Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，在set，hash等数据结构的存储。
- 原子 - Redis的所有操作都是原子性的，同时Redis还支持对几个操作全并后的原子性执行。
- 模式自由：可以把不同结构的文档存储在同一个数据库里
- 面向集合的存储：适合存储JSON风格文件的形式
- 完整的索引支持，对任何属性可索引
- 复制和高可用性：支持服务器之间的数据复制，支持主-从模式及服务器之间的相互复制。复制的主要目的是提供冗余及自动故障转移
- 自动分片：支持水平的数据库集群，可动态添加额外的机器
6.丰富的查询：支持丰富的查询表达方式，查询指令使用JSON形式额标记，可轻易查询文档中的内嵌的对象及数组
- 快速就地更新：查询优化器会分析查询表达式，并生成一个高效的查询计划
8.高效的传统存储方式：支持二进制数据及大型对象
①网站数据：适合实时的插入，更新与查询，并具备网站实时数据存储所需对的复制及高度伸缩性；
②缓存：由于性能很高，也适合作为信息基础设施的缓存层，在系统重启之后，搭建的持久化缓存可以避免下层的数据源过载；
③大尺寸、低价值的数据也是MongoDB的最佳选择，使用传统的关系数据库存储一些数据时可能会比较贵，再次之前很多程序员往往会选择传统的文件进行存储
④高伸缩的场景，非常是个由数十或者数百台服务器组成的数据库
⑤用于对象及json数据的存储，MongoDB的bson数据格式非常适合文档格式化的存储及查询。
而mysql还是更加适用于
①高度事务性的系统。例如银行或者会计系统，传统的关系型数据库目前还是更实用于需要大量原子性复杂事务的应用程序
②传统的商业智能应用，针对特定问题的BI数据库会对产生高度优化的查询方式，对于此类应用，数据仓库可能是更合适的选择
- 用来做缓存-redis的所有数据时放在内存中的
- 可以在某些特定应用场景下替代传统数据库–比如社交类的应用
- 在一些大型系统中，巧妙的实现一些特定的功能：session共享、购物车
这个问题,咱只答三个最主要的应用场景(不可否认还有其他的，但是只答三个主要的),
即以下六个字:解耦、异步、削峰
使用消息队列有什么缺点?
你想啊，本来其他系统只要运行好好的，那你的系统就是正常的。现在你非要加个消息队列进去，那消息
队列挂了，你的系统不是呵呵了。因此，系统可用性降低
要多考虑很多方面的问题，比如一致性问题、如何保证消息不被重复消费，如何保证保证消息可靠传输。
因此，需要考虑的东西更多，系统复杂性增大。
(1)中小型软件公司，建议选RabbitMQ.一方面，erlang语言天生具备高并发的特性，而且他的管理界面用起
来十分方便。正所谓，成也萧何，败也萧何！他的弊端也在这里，虽然RabbitMQ是开源的，然而国内有几个能
定制化开发erlang的程序员呢？所幸，RabbitMQ的社区十分活跃，可以解决开发过程中遇到的bug，这点对于
中小型公司来说十分重要。不考虑rocketmq和kafka的原因是，一方面中小型软件公司不如互联网公司，数据
量没那么大，选消息中间件，应首选功能比较完备的，所以kafka排除。不考虑rocketmq的原因是，
rocketmq是阿里出品，如果阿里放弃维护rocketmq，中小型公司一般抽不出人来进行rocketmq的定制化开
(2)大型软件公司，根据具体使用在rocketMq和kafka之间二选一。一方面，大型软件公司，具备足够的资金
搭建分布式环境，也具备足够大的数据量。针对rocketMQ,大型软件公司也可以抽出人手对rocketMQ进行定制
化开发，毕竟国内有能力改JAVA源码的人，还是相当多的。至于kafka，根据业务场景选择，如果有日志采集
功能，肯定是首选kafka了。具体该选哪个，看使用场景。
如何保证消息队列是高可用的？
rabbitMQ普通集群和镜像集群模式
如何保证消息不被重复消费?
其实无论是那种消息队列，造成重复消费原因其实都是类似的。正常情况下，消费者在消费消息时候，消费完毕
后，会发送一个确认信息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除。只是
不同的消息队列发送的确认信息形式不同,例如RabbitMQ是发送一个ACK确认消息，RocketMQ是返回一个
入门到精通教程),就是每一个消息都有一个offset，kafka消费过消息后，需要提交offset，让消息队列知
道自己已经消费过了。那造成重复消费的原因?，就是因为网络传输等等故障，确认信息没有传送到消息队列，
导致消息队列不知道自己已经消费过该消息了，再次将该消息分发给其他的消费者。
如何解决?这个问题针对业务场景来答分以下3种情况
(1)比如，你拿到这个消息做数据库的insert操作。那就容易了，给这个消息做一个唯一主键，那么就算出现
重复消费的情况，就会导致主键冲突，避免数据库出现脏数据。
(2)再比如，你拿到这个消息做redis的set的操作，那就容易了，不用解决，因为你无论set几次结果都是一
样的，set操作本来就算幂等操作。
(3)如果上面两种情况还不行，上大招。准备一个第三方介质,来做消费记录。以redis为例，给消息分配一个
如何保证消费的可靠性传输?
每种MQ都要从三个角度来分析:生产者弄丢数据、消息队列弄丢数据、消费者弄丢数据
从生产者弄丢数据这个角度来看，RabbitMQ提供transaction和confirm模式来确保生产者不丢消息。
处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。这个持久化配置可以和confirm机制配合使用，你
可以在消息持久化磁盘后，再给生产者发送一个Ack信号。这样，如果消息持久化磁盘之前，rabbitMQ阵亡
了，那么生产者收不到Ack信号，生产者会自动重发。
那么如何持久化呢，这里顺便说一下吧，其实也很容易，就下面两步
1、将queue的持久化标识durable设置为true,则代表是一个持久的队列
这样设置以后，rabbitMQ就算挂了，重启后也能恢复数据
消费者丢数据一般是因为采用了自动确认消息模式。这种模式下，消费者会自动确认收到信息。这时rahbitMQ
会立即将消息删除，这种情况下如果消费者出现异常而没能处理该消息，就会丢失该消息。
至于解决方案，采用手动确认消息即可。
如何保证消息的顺序性？
怎么保证APP接口传数据的安全性
用户登录时传给服务器一个用户的唯一标示（比如token），之后用户在做每一个操作时都必须带上token。来
确保数据传输的安全性。
用ssl（SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。）做双端验证。用Https协
如何确保服务端的接口调用安全？
在设计API时，要保证RESTful API的安全性，主要考虑三个大方面：
1.对受限资源的登录授权
3.对敏感数据进行加密
一、受限资源的登录授权
此流程不是本文重点，不赘述，基本流程如下：
客户端提交账号信息（用户名+密码）到服务端
服务端验证成功，返回AccessToken给客户端存储
3.访问受限资源时，客户端带入AccessToken就可访问。
如果不对请求进行签名认证，那么可以简单的通过fiddler等工具轻易抓包拿到数据，并进行篡改，提交，大规
模批量调用，则会使系统产生大量垃圾数据，系统资源被大量消耗，甚至无法正常使用（另说，当然可以通过
GateWay进行限流），因而我们需要对请求进行签名认证。
1、初始时，服务端存有各App版本的SIGN_KEY，客户端存有对应版本的SIGN_KEY
2、当要发送请求之前，通过签名方法加密，得到一个sign
3、发送请求的时候，连同sign一起发送给服务器端
4、服务器端首先验证时间戳timestamp是否有效，比如是服务器时间戳5分钟之前的请求视为无效；
5、然后取对应版本的SIGN_KEY验证sign是否合法
6、为了防止重放攻击，需要检查sign是否在redis中存储，如不存在则存入redis（缓存5分钟）
这里通过签名参数中包含原有请求的所有参数，改动任意参数，sign值都会不同，因此无法篡改。
由于签名算法中还有imei(设备唯一Id)、timestamp参数，且签名算法为不可逆算法（如md5或sha1），因
而对于正常的每个请求sign值不会重复。此时服务端可以存储5分钟的sign值，来做重放攻击时的验证过滤，
超过5分钟的请求则直接被timestamp校验过滤。
如此便实现了请求认证，防止数据篡改，重放攻击，但是需要确保App密钥(SIGN_KEY)的安全保存，其优点是
容易理解与实现，缺点是需要承担安全保存密钥和定期更新密钥的负担。
1)、部署SSL基础设施（即HTTPS），敏感数据的传输全部基于SSL。
2)、仅对部分敏感数据做加密（例如账号+密码），并加入某种随机数作为加密盐，以防范数据被篡改。
