2年java,蚂蚁一面,卒

其实我一个都没答上来。并不是因为我笨,是因为我不会。在大扰的帮助下,现在我会了,求求你再给我一个机会。

TreeSet/HashSet 区别

顾名思义,首先是结构上的不同
1、TreeSet背后的结构是TreeMap,也就是红黑树,能够实现自动排序。它通过equals方法或者compareTo方法进行内容的比较。
2、HashSet背后是HashMap,key是无序的,只能做外部排序。既然是Hash,那么就要重写其中对象的hashCode和equals方法

另外,还有个细微的差别可以拿来装b:
1、HashSet可以接受null值,有且只有一个
2、TreeSet默认不可以接受null值,会直接抛出空指针异常

set里没有重复数据,TreeSet里连虚无都没有。

HashMap 如何解决冲突,扩容机制

烂大街的问题,问哪答哪吧。这样的东西就是靠背。

HashMap的内部结构其实是数组+链表(java8后如果长度大于8则转换为红黑树)。HashMap初始化时,默认有16个hash槽。
存入对象时,首先,通过对象的hashCode,定位到hash槽。如果多个对象同时落入同一个槽,那么就会使用链表解决本槽上的冲突。
HashMap在创建时,会有一个负载因子。每次put操作,都会检查当前容量是否会超出阈值(initailCapacity*loadFactor)。如果超出,则扩容为当前的两倍。扩容后,数据需要重新散列,也就是transfer方法。

经验:resize非常耗时,所以如果能够提前预估容量,可以把initailCapacity提前固定下来。

ConcurrentHashMap 如何做到高并发的

简单点说,使用了分段锁(分离锁)。每一把锁用于锁住容器中的一部分数据,减少线程间对锁的竞争。

这道题往深里问会死人的,篇幅有限,不啰嗦。

线程池平常怎么用

普通的场景,使用工厂类Executors创建就可以了。常用的有Single、Fixed、Cached三种。
更多时候,为了更精细的控制,会直接对ThreadPoolExecutor类进行定制。阿里的规范也要求这么搞(当然要舔一舔),我尤其关心其中的阻塞队列和饱和策略。
当然,你只有对阻塞队列和拒绝策略熟悉才能这么说。否则给自己挖坑就太不聪明了。

他们很喜欢你提到阿里规范,这让我觉得jdk设计的很low

多个线程等待到某一节点然后统一放行有几种实现方式?

最经典的就是CountDownLatch,主线程阻塞在await方法,每个线程调用countDown。可以解决一些经典的赛马问题。
还有一个变种就是CyclicBarrier。每个线程都阻塞在await方法,达到一定阈值集体放行。
另外还可以使用一些较初级的api,比如Thread的join方法。Future的get方法等。复杂不推荐。

也可以答sleep啊。有什么问题么?我用while等待一个变量也是可以的,但我为什么要这么做?

数据库索引结构

B+ Tree,为了适应缓慢的磁盘而生的一种索引结构。必须保证按照索引的最左前缀查询。
Hash 和HashMap类似,处理冲突的方式是链表

pg的索引结构就多了去了。Mysql这么少怎么感觉怪怪的?难道要我回答存储引擎的区别?

select * from t where a=? and b>? order by c limit 0,100 如何加索引

知道这个就结论就行了=>当order by 字段出现在where条件中时,才会利用索引而无需排序操作。其他情况,order by不会出现排序操作。

按照最左原则,我可以创建 (a,b) 的索引。

什么是聚簇索引和非聚簇索引

一个表只能有一个聚簇索引。主索引文件和数据文件为同一份文件,默认的InnoDB就支持聚簇索引,B+ Tree的叶子节点上的data就是数据本身。

而MyISAM就不支持聚簇索引,它的叶子结点存放的不是数据本身,而是数据存放的地址。在文件结构上,会分为一个索引文件、一个数据文件。

对编程来说没什么鸟用。

了解 CAP 吗?redis 里的 CAP 是怎样的?

  • Consistency 一致性
  • Availability 可用性
  • Partition tolerance 分区容错一般,都在C、A之间进行权衡。

redis简单主从模式侧重于CP的,即对于一致性要求较高。redis-cluster,则属于AP类型,更加强调可用性

cap就是帽子,绿油油的那种

如何理解幂等?项目中接口的幂等是如何做的?

幂等是指多次执行,影响相同。

比如大多数Post操作,重复提交订单等,最终只会有一个订单生成成功。还有一种情况就是消息,由于大多数MQ之保证at least once,所以消息有时会重复。

1、对于Post请求,我一般在请求成功后,强制跳转到其他页面,避免刷新提交。
2、复杂的操作一般使用流水号来实现。
3、某些不带流水号的消息,处理的时候,就要进行多次校验和check,甚至引入消息状态表,来保证幂等。

就如同表白,每次表白都是被拒绝,因为我就是那个id!

解释下乐观锁悲观锁

悲观锁总是假设情况最坏,每次操作数据都认为别人会修改,就加锁来保证安全。后面的访问者只能等待。数据库中的行锁、表锁,java中的同步关键字等,都属于悲观锁。

乐观锁正好相反,总是假设最好的情况,不用对数据加锁,但多了一次额外的判断操作。比如concurrent包里大量的CAS操作、判断新旧版本号机制等。

悲观锁是老婆,有你独占;乐观锁是炮友,按预约规划

JVM 判断对象是否回收?

答案就是GC roots。也就是从根对象出发,没有任何一个对象引用到它,那么就判断这个对象是不可达的。

通常被骂“断子绝孙”的人,就是要被回收的root

GCROOT 有哪些?

1 、 虚拟机栈(栈帧中的本地变量表)中引用的对象。
2、 本地方法栈中JNI(即一般说的native方法)引用的对象。
3、 方法区中的静态变量和常量引用的对象。
4、活跃线程的引用对象

所以不要让他们过度繁殖。

反射能获得类里面方法的名称吗?参数名称呢?参数类型呢?

都可以。

java8以后,通过Parameter类获取参数名称。但有前提,需要加编译开关。

javac -parameters

复制代码默认是关闭的,干!

问题都偏到月球上去了

动态代理的实现方式?CgLib 和 jdk 的代理有什么区别?

java中通过实现InvocationHandler接口来实现动态代理,然后使用Proxy将其初始化。
Cglib使用了ASM自己吗生成框架,可以代理普通类,但代理不了final类,而jdk的只能代理接口。

在spring里,cglib胜出

分布式锁有哪些主流实现方式?redis 和 zk 锁有什么区别?

大体分为两类。

乐观锁:
基于版本号机制和CAS实现,与存放版本号的存储无关。

悲观锁:
1、基于数据库记录,进入时写数据,退出时删记录
2、数据库行锁,比如分布式quartz,它是一把排它锁
3、基于Redis的setnx函数(由于大多数会设置超时,所以推荐用带px的set原子函数)
4、基于zookeeper

区别:
redis获取锁是轮训机制。锁释放后会有多个调用者争抢,某些任务有可能饿死。
zk是监听机制,有变动会接到通知。除了非公平锁,也可以实现公平锁。

从优雅性来说,显然redis胜出

ThreadLocal 作用是什么?说下用法

ThreadLocal用来隔离数据。ThreadLocal中存放的是与线程相关的数据,底层实际上是一个map,通过线程可以获取存储数据的map。

这种方式与Servlet中的Request类似。

一些需要绑定到线程的数据,比如一些线程的统计数据,就可以放在这里。

据说这是一种线程同步方式,但它明显无锁啊。

ThreadLocal有没有优化方式?

ThreadLocal中的Map性能较差,解决Hash采用的线性探测方法。
Netty就对它进行了优化,优化方式是继承了Thread类,实现了自己的FastThreadLocal。它使用

搞不懂jdk,明明有O(1)的Map,非要自己造个更慢的轮子,为什么呢?话说,这个问题,简直又偏到火星了。

设计秒杀系统要考虑哪些点?

1、数据预热 秒杀都是瞬时操作,不要等流量来了再加载数据。可以提前对数据进行预热,比如加载到缓存等。
2、缓存 包括CDN缓存和数据缓存。保证缓存系统的高可用,数据随后落地。
3、解决超卖 引入MQ,串行化操作库存,达到阈值后不再消费,并关闭购买功能。或者直接操作缓存。
4、流量削峰 通过引入MQ,将耗时业务进行削峰,平稳处理用户需求。
5、熔断限流 熔断,优先保证主要业务的进行。限流,识别异常流量,进行封锁;同时,允许部分请求失败。
6、弹性扩容 在判断系统负载达到极限时,可以通过增加服务器的途径抵抗峰值。需要打通运维环境,能够快速扩容。

怕就怕抓住一点问到底。秒杀个屁啊,淘宝的秒杀要么抢不到,要么500!

算了,杭州咱也不想去。下次试试阿里最烂的部门,看看要求是不是低点,能不能过。

大家可以加我的程序员交流群:833145934,群内有阿里,京东等技术大牛讲解的最新Java架构技术。作为给广大朋友的加群福利——分布式(Dubbo、Redis、RabbitMQ、Netty、RPC、Zookeeper、高并发、高可用架构)/微服务(Spring Boot、Spring Cloud)/源码(Spring、Mybatis)/性能优化(JVM、TomCat、MySQL)【加群备注好消息领取最新面试资料】

扫码关注作者公众号号
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,013评论 6 481
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,205评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 152,370评论 0 342
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,168评论 1 278
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,153评论 5 371
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,954评论 1 283
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,271评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,916评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,382评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,877评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,989评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,624评论 4 322
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,209评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,199评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,418评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,401评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,700评论 2 345

推荐阅读更多精彩内容

  • 其实我一个都没答上来。并不是因为我笨,是因为我不会。在大扰的帮助下,现在我会了,求求你再给我一个机会。 TreeS...
    4553675200ad阅读 413评论 0 1
  • 包含的重点内容:JAVA基础JVM 知识开源框架知识操作系统多线程TCP 与 HTTP架构设计与分布式算法数据库知...
    消失er阅读 4,295评论 1 10
  • 九种基本数据类型的大小,以及他们的封装类。(1)九种基本数据类型和封装类 (2)自动装箱和自动拆箱 什么是自动装箱...
    关玮琳linSir阅读 1,878评论 0 47
  • Java SE 基础: 封装、继承、多态 封装: 概念:就是把对象的属性和操作(或服务)结合为一个独立的整体,并尽...
    Jayden_Cao阅读 2,099评论 0 8
  • 一 基础篇 1.1 Java基础 面向对象的特征抽象:将一类对象的共同特征总结出来构建类的过程。继承:对已有类的一...
    essential_note阅读 686评论 0 0