饿了么日常实习后端一面 45min

互联网加班是真的累，而且基本就是常态，不自己去实习一趟，根本体会不到有多夸张。大部分大厂其实都这样，晚上十一二点下班都不算稀奇，天天熬到那么晚，整个人都处于疲惫状态，身体和精神都扛不住，这种节奏真的太难受了。犹豫去不去互联网工作。

实习日常主打一个手忙脚乱，改不完的文档、算错的报表，偶尔还会因为萌新操作被前辈温柔提点，忙到抬头发现天都黑了也是常事。但没关系，至少我的下班步伐很曼妙！掐点关电脑的瞬间浑身松绑，背上包迈着轻快的步子走出公司，晚风裹着街边小吃的香味，逛便利店挑根烤肠喝瓶汽水，慢悠悠走回出租屋，所有的小疲惫都被这曼妙的下班节奏抚平啦。

第一，所有男生听好：如果你和你老婆吵架了，买黄金项链给你老婆。第二，所有女生听好，如果你对象惹你生气了，立刻去刷他的卡给自己买黄金项链。我本科舍友从20年开始这么干，她3万的黄金已经能卖10万还多了。

鼠鼠最近在看八股，关于threadlocal内存泄漏原理大家都倒背如流，但我自己探索发现，不知道大家是否考虑过以下问题？（我是第一次放这种文章，如有不对，请斧正）既然threadlocal是因为entry的key弱引用导致的内存泄漏，那我如果将value也继承弱引用，能否解决内存泄漏问题呢？弱引用：当发生GC时，弱引用所指向的对象没有被任何强引用指向会被JVM回收正常的情况为entry中的key为弱引用，而entry中的value为强引用，key存放的是threadlocal对象，如果threadlocal没有被任何强引用指向，那么在下一次GC时，该对象会被回收，出现key为null，而value不为null的情况，所以发生内存泄漏，永远无法被JVM回收但如果我们把threadlocal设置为常量，那也就是平时我们使用的形式final static，这样threadlocal永远被强引用指向，不会被JVM回收，同时也不会出现key为null而value不为null的情况，但同时要注意的是，如果我们value存放的是map之类的数据结构或者大对象，随着时间的推移，我们不断往map中添加数据，这样这个map或者大对象一直存活，这样会导致堆的内存越来越大，从而导致内存泄漏和内存溢出的情况。那换个方向想，如果我们把value继承弱引用，能否解决内存泄漏问题？实际上是不可以的，可以剖解引用链key的引用链：业务代码引用->threadlocal对象value的引用链：threadlocalmap的entry引用->实际的value比如：threadlocal.set(new user());此时在堆内存中创建这个user对象，此时threadlocalmap中的entry引用他，他为弱引用如果我们把threadlocal对象设置为常量，那么key虽为弱引用，但永远不会被回收，那么会出现一种情况，此时没有任何强引用指向这个user对象，当发生GC时，JVM会将该对象回收，那么下一次我们get获取vlaue值时，他为null,那么就出现事故了，明明我存了这个值，但为什么会凭空消失呢？就是因为value继承了弱引用，导致value没有强引用指向时，导致被垃圾回收了。那又可以想到一种情况，既然我把threadlocal设置为常量，那我把threadlocal不设置常量呢？那这样会出现非常恶心的情况，只要我们有一方没有被强引用指向，那么如果发生GC，就会被回收，但又无法保证在发生GC时，key和value都没有强引用指向，所以这个方法并不适用。并且我们使用threadlocal的初衷本来就是想在一个线程中共享变量，如果不把其定义为static，那如何实现在不同的类中共享变量呢，那岂不是就是局部变量，那还不如传参的方式呢。所以static final可以保证你的key不会丢失，而value坚持强引用，保证你的value不为空为了解决上述问题，还是要记得remove()来保证内存不泄露。