蚂蚁金服P6面试
一、自我介绍、本身作的项目和技术领域前端
2、项目中的监控：那个监控指标常见的有哪些？java
性能测试须要使用不一样的工具，结合系统日志，监控服务器、应用等方面的多项指标。如下阐述监控指标、监控工具、瓶颈分析。linux
服务端监控指标ios
性能测试一般须要监控的指标包括：nginx
服务器 Linux（包括CPU、Memory、Load、I/O）。git
数据库：Mysql（缓存命中、索引、单条SQL性能、数据库线程数、数据池链接数）。面试
中间件：1.tomcat 二、nginx 三、memcache（包括线程数、链接数、日志）。算法
网络： 吞吐量、吞吐率。sql
应用： jvm内存、日志、Full GC频率。数据库
客户端监控指标
LoadRunner：用户执行状况、场景状态、事务响应时间、TPS、吞吐量等。
测试机资源：CPU、Memory、网络、磁盘空间。
经常使用监控工具
Jstat
监控java 进程GC状况，判断GC是否正常。
JConsole
监控java内存、javaCPU使用率、线程执行状况等，须要在JVM参数中进行配置。
JMap
监控java程序是否有内存泄漏，须要配合eclipse插件或者MemoryAnalyzer来使用。
JProfiler
全面监控每一个节点的CPU使用率、内存使用率、响应时间累计值、线程执行状况等，须要在JVM参数中进行配置。
Nmon
全面监控linux系统资源使用状况，包括CPU、内存、I/O等，可独立于应用监控。
Probe
全面监控tomcat的线程、内存、JVM CPU 使用率、OS 和 JVM内存使用率、交换区使用率、每30秒内接收到的请求数目等等
Memadim
1. 服务器参数监控：STATS、SETTINGS、ITEMS、SLABS、SIZES实时刷新
2. 服务器性能监控：GET、DELETE、INCR、DECR、CAS等经常使用操做命中率实时监控
3. 支持数据遍历，方便对存储内容进行监视
4. 支持条件查询，筛选出知足条件的KEY或VALUE
性能分析
分析信息来源
5. 监控工具所采集的信息。包括TPS、响应时间、用户并发数、JVM内存、Full GC频率、tomcat链接数，数据sql执行时间、memcache的命中率、nginx的链接数等。
6. 应用服务器的日志。包括错误日志、超时日志等。
7. 项目配合人员所提供的信息。包括DBA提供的数据库监控信息、开发人员提供的代码逻辑信息。
分析标准
1.经过性能指标的表现形式，分析性能是否稳定。好比：
2.响应时间是否符合性能预期，表现是否稳定。
3.应用日志中，超时的几率，是否在可接受的范围以内。
8. TPS维持在多大的范围内，是否有波形出现，标准差有多少，是否符合预期。
9. 服务器CPU、内存、load是否在合理的范围内，等等。
分析工具
对于部分性能指标，可借助自动分析工具，统计出数据的整体趋势：
一、LoadRunner analysis 分析
LoadRunneranalysis是loadrunner的一个部件，用于将运行过程当中所采集到的数据生成报表，主要用于采集TPS、响应时间、吞吐量、服务器资源使用状况等变化趋势。
二、Memory Analyzer分析
Memory Analyzer工具能够解析Jmap dump出来的内存信息，查找是否有内存泄漏。
三、nmon_analyser分析
nmon工具能够采集服务器的资源信息。列出CPU、MEM、网络、I/O等资源指标的使用状况。
四、MONyog分析
经过此工具咱们可以跟踪到执行比较慢的sql语句，而且能够分析出sql语句执行时扫描的行数，使用的索引状况。
三、微服务涉及到的技术以及须要注意的问题有哪些？
微服务条目 技术 备注
服务开发 Springboot、Spring、SpringMVC
服务配置与管理 Netflix公司的Archaius、阿里的Diamond等
服务注册与发现 Eureka、Consul、Zookeeper等
服务调用 REST、RPC、gRPC
服务熔断器 Hystrix、Envoy等
负载均衡 Ribbon、Nginx等
服务接口调用（客户端调用服务发简单工具） Feign等
消息队列 kafka、RabbitMQ、ActiveMQ等
服务配置中心管理 SpringCloudConfig、Chef等
服务路由（API网关） Zuul等
服务监控 Zabbix、Nagios、Metrics、Spectator等
全链路追踪 Zipkin、Brave、Dapper等
服务部署 Docker、OpenStack、Kubernetes等
数据流操做开发包 SpringCloud Stream（封装与Redis，Rabbit、Kafka等发送接收消息）
事件消息总线
SpringCloud Bus
使用微服务时的注意事项
在微服务架构带了不少好处的同时，你须要认识到的很重要的一点，你正在进入分布式计算的世界。分布式计算老是一个复杂的课题，微服务也不例外。在开始使用微服务时，有几件事你须要注意到。
复杂性增长
在微服务架构中，有不少可移动的组件，因此对服务的管理将变得更加复杂。相比于单节点应用的部署，你要部署成百上千的服务，还要让它们在一块儿无缝的工做。这须要服务注册和服务发现解决方案，以便一个新的或者更新的服务可以让本身被系统知道，可以被其余服务检测到。你也须要确保全部的服务都启动而且在运行当中，没有耗尽磁盘空间或者其余资源，而且保证足够的性能。全部的服务一般都会须要负载均衡，而且使用同步或者异步的消息发送来进行通信。集群管理和编排工具会帮助你解决一些问题，可是也须要你了解这些工具是如何进行工做的。在这系列博客的第二部分，咱们将更深刻的了解集群管理和编排如何帮助微服务进行工做的。
网络拥塞和延迟
微服务用来通信的API使用的是标准协议，好比HTTP，因此网络成为重要因素。想象一下在一个应用中有数百个服务，一般一个请求就会跨多个不一样的服务，不难看出，若是网络方面没有给予足够的重视的话，将会对应用的总体性能形成多大的影响。另外一个常常被忽略的地方是数据的序列化和反序列化。有时，相同的数据从一个服务传递到另外一个服务，它会被序列化和发序列化屡次，从而大大增长了网络的延迟。有几种模式可使用，好比数据缓存和服务，来限制请求的数量。对于序列化问题，你可使用高效的序列化格式，而且在整个服务框架中使用这个共用的格式。这可能会在服务间传递数据时减小一些步骤，不须要再次序列化。
数据一致性
由于每个微服务一般都会有它本身的状态存储，因此你必需要面临分散数据所带来的数据一致性和完整性挑战。考虑下面的场景，订单服务所引用的数据在另外一个服务当中，好比产品目录服务，你就须要维护该服务中的数据完整性。如今你在每一个服务中都有一些相同的数据，必需要保证一致性；若是一个服务节点中的数据变动，其余节点中的数据必须一块儿进行变动。若是在产品目录服务中的数据被删除或者更新，好比有效产品项的数量，订单服务就须要知道这种变化。处理这种一致性挑战，以及诸如此类的数据一致性概念，可能很可贵到正确的结果，可是幸运的是，这个问题已经被解决了。好比，你可使用事件源或者通知服务之类的模式，将变化的数据发布给已经订阅这种变化和更新的数据消费服务。
容错和弹性
微服务应用的特性之一是，即使在发生灾难性故障时，它仍可以实现容错。因为在网络中存在不少微服务，所以，在微服务架构中，故障也更为广泛，也更具挑战性。你可能想知道，这是怎么发生的呢？由于微服务一般都运行在它们本身的进程或者容器当中，其余的微服务是不会直接影响到它的进程的。因此，一个坏的微服务怎么会击倒整个应用？咱们来看个例子，若是一个微服务花费太长时间来进行相应，在服务调用中耗尽全部的线程资源，它就会引发整个调用链的级联故障。对故障进行合适的处理，也会对应用正常运行时间的SLA产生影响。咱们假设你的应用须要有99.9%的正常运行时间的SLA，也就是说每月只容许大约44分钟的停机。你的应用包含3个微服务，每一个都提供99.9%的正常运行时间。每个服务都有可能在不一样的时间出现中止服务，你就会看到潜在的停机时间大约是132分钟，明显影响了整个应用正常运行时间的SLA。
要进行故障处理，让你的应用实现容错，你须要实现弹性模式，好比超时、重试、熔断机制和隔离机制，这对于开发人员来讲都是很是具备挑战性的。
诊断
在微服务应用中，日志和追踪须要一个合理的策略。须要对日志聚合和分析进行认真的思考，由于微服务应用中有成百上千个服务，生成了大量的日志。此外，请求一般会跨越多个服务，因此，找到一种方法在整个系统中对请求进行标记很是重要，让你可以看清跨越全部服务的整个请求。这一般都是经过使用关联或者传递给全部下游服务的活动ID来实现的，每个服务都会将这个ID写入它的日志。因为服务是由不一样的团队开发的，因此肯定一种统一的日志格式也很重要。微服务应用的整体诊断与调试是颇有挑战性的，必须在一开始就计划好。在本系列的第三部分，咱们将介绍一些诊断的最佳实践。
版本控制
在单体系统中，调用一个接口的代码一般与接口的实现部署在一块儿。接口的中断变动一般是在集成测试或者构建期间被捕获。在微服务世界中，一个微服务接口的变动不须要调用它的微服务当即进行处理，由于他们可能有不一样的发布节奏。为了保证调用服务仍然可以按照预期进行工做，须要整个团队考虑而且承认服务版本控制技术。
DevOps
现金的DevOps，自动化和监控是微服务运营成功的关键。在生产环境中进行测试一般是一个目标，实现这个目标须要更多的强调监控，使咱们可以快速的检测到异常和问题，而且根据需进行回滚。在自动化方面进行投资，使用诸如Blue-Green Deployment、Canaries、A/B Testing和特性标志等工具和最佳实践，很是重要。创建起一个定义良好的工做流，让开发和运营一块儿工做，带来敏捷、高质量的发布，很是有挑战性。本系列博客的第三部分将对DevOps的流程进行更详细的介绍。
四、注册中心你了解了哪些？
微服务做为一项在云中部署应用和服务的新技术已成为当下最新的热门话题。现就微服务中注册中心的选型作一下记录。
当下实现微服务主要有两种选择，DUBBO和Spring Cloud，他们分别选择zookeeper和eureka做为注册中心。
1、什么是CAP定理
在分布式系统领域有个著名的CAP定理：C——数据一致性，A——服务可用性，P——服务对网络分区故障的容错性。这三个特性在任何分布式系统中不能同时知足，最多同时知足两个。
2、Zookeeper
Zookeeper是著名Hadoop的一个子项目，不少场景下Zookeeper也做为Service发现服务解决方案。
不少场景下Zookeeper也做为Service发现服务解决方案。Zookeeper保证的是CP，即任什么时候刻对Zookeeper的访问请求能获得一致的数据结果，同时系统对网络分割具有容错性，可是它不能保证每次服务请求的可用性。从实际状况来分析，在使用Zookeeper获取服务列表时，若是zookeeper正在选主，或者Zookeeper集群中半数以上机器不可用，那么将就没法得到数据了。因此说，Zookeeper不能保证服务可用性。
诚然，对于大多数分布式环境，尤为是涉及到数据存储的场景，数据一致性应该是首先被保证的，这也是zookeeper设计成CP的缘由。
3、Eureka
Eureka自己是Netflix开源的一款提供服务注册和发现的产品，而且提供了相应的Java封装。Eureka保证的AP，在它的实现中，节点之间是相互平等的，部分注册中心的节点挂掉也不会对集群形成影响，即便集群只剩一个节点存活，也能够正常提供发现服务。哪怕是全部的服务注册节点都挂了，Eureka Clients上也会缓存服务调用的信息。这就保证了咱们微服务之间的互相调用是足够健壮的。
对于服务发现场景来讲：针对同一个服务，即便注册中心的不一样节点保存的服务提供者信息不尽相同，也并不会形成灾难性的后果。由于对于服务消费者来讲，能消费才是最重要的——拿到可能不正确的服务实例信息后尝试消费一下，也好过由于没法获取实例信息而不去消费。
因此，对于服务发现而言，可用性比数据一致性更加剧要——AP赛过CP。
五、consul 的可靠性你了解吗？
六、consul 的机制你有没有具体深刻过？有没有和其余的注册中心对比过？
七、项目用 Spring 比较多，有没有了解 Spring 的原理？AOP 和 IOC 的原理
八、Spring Boot除了自动配置，相比传统的 Spring 有什么其余的区别？
Spring Boot能够创建独立的Spring应用程序；
内嵌了如Tomcat，Jetty和Undertow这样的容器，也就是说能够直接跑起来，用不着再作部署工做了。
无需再像Spring那样搞一堆繁琐的xml文件的配置；
能够自动配置Spring；
提供了一些现有的功能，如量度工具，表单数据验证以及一些外部配置这样的一些第三方功能；
提供的POM能够简化Maven的配置；
九、Spring Cloud 有了解多少？
Spring Cloud是一个微服务框架，相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系统解决方案。
Spring Cloud对微服务基础框架Netflix的多个开源组件进行了封装，同时又实现了和云端平台以及和Spring Boot开发框架的集成。
Spring Cloud为微服务架构开发涉及的配置管理，服务治理，熔断机制，智能路由，微代理，控制总线，一次性token，全局一致性锁，leader选举，分布式session，集群状态管理等操做提供了一种简单的开发方式。
Spring Cloud 为开发者提供了快速构建分布式系统的工具，开发者能够快速的启动服务或构建应用、同时可以快速和云平台资源进行对接。
- Spring Cloud Config：配置管理工具，支持使用Git存储配置内容，支持应用配置的外部化存储，支持客户端配置信息刷新、加解密配置内容等
- Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与Spring Cloud Config联合实现热部署。
- Spring Cloud Netflix：针对多种Netflix组件提供的开发工具包，其中包括Eureka、Hystrix、Zuul、Archaius等。
- Netflix Eureka：一个基于rest服务的服务治理组件，包括服务注册中心、服务注册与服务发现机制的实现，实现了云端负载均衡和中间层服务器的故障转移。
- Netflix Hystrix：容错管理工具，实现断路器模式，经过控制服务的节点,从而对延迟和故障提供更强大的容错能力。
- Netflix Ribbon：客户端负载均衡的服务调用组件。
- Netflix Feign：基于Ribbon和Hystrix的声明式服务调用组件。
- Netflix Zuul：微服务网关，提供动态路由，访问过滤等服务。
- Netflix Archaius：配置管理API，包含一系列配置管理API，提供动态类型化属性、线程安全配置操做、轮询框架、回调机制等功能。
- Spring Cloud for Cloud Foundry：经过Oauth2协议绑定服务到CloudFoundry，CloudFoundry是VMware推出的开源PaaS云平台。
- Spring Cloud Sleuth：日志收集工具包，封装了Dapper,Zipkin和HTrace操做。
- Spring Cloud Data Flow：大数据操做工具，经过命令行方式操做数据流。
- Spring Cloud Security：安全工具包，为你的应用程序添加安全控制，主要是指OAuth2。
- Spring Cloud Consul：封装了Consul操做，consul是一个服务发现与配置工具，与Docker容器能够无缝集成。
- Spring Cloud Zookeeper：操做Zookeeper的工具包，用于使用zookeeper方式的服务注册和发现。
- Spring Cloud Stream：数据流操做开发包，封装了与Redis,Rabbit、Kafka等发送接收消息。
- Spring Cloud CLI：基于 Spring Boot CLI，可让你以命令行方式快速创建云组件。
十、Spring Bean 的生命周期
十一、HashMap 和 hashTable 区别？
1.Hashtable是线程安全的，它的每一个方法中都加入了Synchronize方法
2.HashMap是继承自AbstractMap类，而HashTable是继承自Dictionary类。不过它们都实现了同时实现了map、Cloneable（可复制）、Serializable（可序列化）这三个接口
3.当须要多线程操做的时候可使用线程安全的ConcurrentHashMap。ConcurrentHashMap虽然也是线程安全的，可是它的效率比Hashtable要高好多倍。由于ConcurrentHashMap使用了分段锁，并不对整个数据进行锁定
4.HashMap的get过程是先获得key的hash值，再把这个hash值与length-1按位与（取余），获得table数组的下标。取出这个下标值的key，与传入的key比较，若是相同那就是这个了。若是不一样呢，那就沿着这个单向链表向后找，直到找到或找到结束也找不到。这里的length是有特色的，是2的n次方。
5.HashMap扩容机制是在put时，容量不够用的时候。由于每一个元素都是一个单向链表，因此map里放的实际数量老是大于等于申请的空间。
6.HashMap能够接受null键值和值，而Hashtable则不能。
7.HashMap是非synchronized因此HashMap很快。
8.hashcode相同，因此两个对象是相等的，HashMap将会抛出异常，或者不会存储它们。而后面试官可能会提醒他们有equals()和hashCode()两个方法，并告诉他们两个对象就算hashcode相同，可是它们可能并不相等。一些面试者可能就此放弃，而另一些还能继续挺进，他们回答“由于hashcode相同，因此它们的bucket位置相同，‘碰撞’会发生。由于HashMap使用链表存储对象，这个Entry(包含有键值对的Map.Entry对象)会存储在链表中。”这个答案很是的合理，虽然有不少种处理碰撞的方法，这种方法是最简单的，也正是HashMap的处理方法
9.当一个map填满了75%的bucket时候，和其它集合类(如ArrayList等)同样，将会建立原来HashMap大小的两倍的bucket数组，来从新调整map的大小，并将原来的对象放入新的bucket数组中。这个过程叫做rehashing，由于它调用hash方法找到新的bucket位置
。
10.当从新调整HashMap大小的时候，确实存在条件竞争，由于若是两个线程都发现HashMap须要从新调整大小了，它们会同时试着调整大小。在调整大小的过程当中，存储在链表中的元素的次序会反过来，由于移动到新的bucket位置的时候，HashMap并不会将元素放在链表的尾部，而是放在头部，这是为了不尾部遍历(tail traversing)。若是条件竞争发生了，那么就死循环了。这个时候，你能够质问面试官，为何这么奇怪，要在多线程的环境下使用HashMap呢？
十二、Object 的 hashcode 方法重写了，equals 方法要不要改？
1三、Hashmap 线程不安全的出现场景
1四、线上服务 CPU 很高该怎么作？有哪些措施能够找到问题
1五、JDK 中有哪几个线程池？顺带把线程池讲了个遍
1六、SQL 优化的常见方法有哪些
1七、SQL 索引的顺序，字段的顺序
1八、查看 SQL 是否是使用了索引？（有什么工具）
1九、TCP 和 UDP 的区别？TCP 数据传输过程当中怎么作到可靠的？
20、说下你知道的排序算法吧
2一、查找一个数组的中位数？
2二、项目中你学到了什么技术？（把三项目具体描述了好久）
2三、微服务划分的粒度
2四、微服务的高可用怎么保证的？
2五、经常使用的负载均衡，该怎么用，你能说下吗？
2六、网关可以为后端服务带来哪些好处？
2七、Spring Bean 的生命周期
2八、xml 中配置的 init、destroy 方法怎么能够作到调用具体的方法？
2九、反射的机制
30、Object 类中的方法
3一、hashcode 和 equals 方法经常使用地方
3二、对象比较是否相同
3三、hashmap put 方法存放的时候怎么判断是不是重复的
3四、Object toString 方法经常使用的地方，为何要重写该方法
3五、Set 和 List 区别？
3六、ArrayList 和 LinkedList 区别
3七、若是存取相同的数据，ArrayList 和 LinkedList 谁占用空间更大？
3八、Set 存的顺序是有序的吗？
3九、常见 Set 的实现有哪些？
40、TreeSet 对存入对数据有什么要求呢？
4一、HashSet 的底层实现呢
4二、TreeSet 底层源码有看过吗？
4三、HashSet 是否是线程安全的？为何不是线程安全的？
4四、Java 中有哪些线程安全的 Map？
4五、Concurrenthashmap 是怎么作到线程安全的？
4六、HashTable 你了解过吗？
4七、如何保证线程安全问题？
4八、synchronized、lock
4九、volatile 的原子性问题？为何 i++ 这种不支持原子性？从计算机原理的设计来说下不能保证原子性的缘由
50、happens before 原理
5一、cas 操做
5二、lock 和 synchronized 的区别？
5三、公平锁和非公平锁
5四、Java 读写锁
5五、读写锁设计主要解决什么问题？
5六、你项目除了写 Java 代码，还有前端代码，那你知道前端有哪些框架吗？
5七、MySQL 分页查询语句
5八、MySQL 事务特性和隔离级别
5九、不可重复读会出如今什么场景？
60、sql having 的使用场景
6一、前端浏览器地址的一个 http 请求到后端整个流程是怎么样？可以说下吗？
6二、http 默认端口，https 默认端口
6三、DNS 你知道是干吗的吗？
6四、大家开发用的 ide 是啥？你能说下 idea 的经常使用几个快捷键吧？
6五、代码版本管理大家用的是啥？
6六、git rebase 和 merge 有什么区别？
6七、大家公司加班多吗？