TCP三次握手而不是两次握手的原因
为了实现可靠数据传输，如果只是两次握手，只要client端能确认数据可靠，Server端发送的ack不确定Client端是否接收正确，得不到确认；
三次握手主要是使客户端和服务端都确认对方可靠；
TCP四次挥手的原因
为了保证数据发送完成，Client端关闭连接，Server端首先接收到Client的第一步挥手会返回客户端收到了关闭连接的消息，然后再服务端发送完数据或者确认没有数据要发送的时候主要和Client端发送准备关闭，客户端接收后和服务端发送关闭
主要原因是TCP连接是全双工的，因此每个方向都必须单独进行关闭:当一方完成它的数据发送任务后就发送一个FIN来终止这个方向的连接，对端收到后回复一个ACK报文，这样双向就需要四次交互。
为什么TIME_WAIT状态需要经过2MSL才能返回到CLOSE状态
为了保证主动关闭方发送的最后一个ACK报文能够到达被动关闭方。
GC回收机制
回收的是无任何引用的对象占据的内存空间而不是对象本身，当对象没有任何引用时其占据的内存空间随即被收回备用，此时对象也就被销毁
怎么判断对象是否可以被回收？
引用计数法
可达性分析法
当一个对象到GC Roots没有任何引用链相连时，就证明此对象是不可用的。
根搜索算法来判定对象是否可以被回收。
通过GcRoot来找到可达对象标记为存活，其他对象的空间会被GC回收。
回收算法有标记-清除算法，标记-整理算法，复制算法，分代回收。
内存泄漏的原因
内存泄漏的原因归根到底就是当需要被回收变量的内存被其他变量引用持有，导致内存回收失败
长生命周期对象持有短生命周期对象的引用，并且是强引用持有导致GC没办法释放短生命周期对象；
例如Handler持有TextView，TextView持有Activity 的强引用，这样也会造成内存泄漏。
Activity destory的时候没办法正常GC回收。
因为handler的消息机制，当Activity销毁，handler中还有为处理的Message时就会持有activity的引用从而导致无法被回收，出现内存泄漏。
可以使用弱引用或者removeCallbacksAndMessages
资源未关闭造成的内存泄漏
例如Bitmap，需要bitmap.recycle(),然后bitmap = null；强引用置为null后可以被回收，前提是没有被其他位置引用；
RecycleView的回收复用机制
回收和复用的都是ViewHolder对象，回收发生再itemView消失的时候，复用发生再itemView不可见到可见的时候
在 setLayoutManager、setAdapter、notifyDataSetChanged 或者滑动时等等这些场景都会触发回收复用机制的工作。
主要是复用ViewHolder，执行onBindViewHolder() 重新绑定数据
1.首先在mCachedViews中找到ViewHolder，这里找到的ViewHolder是不需要绑定数据的，是匹配postion后返回的ViewHolder，可以直接显示。
2.然后去ViewPool中找，根据type找，只要相同type的ViewPool中有ViewHolder则直接返回，然后调用onBindViewHolder() 绑定数据
3.如果上述没有找到则说明没有可以复用的，则需要创建新的ViewHolder();
4.如果mCachedViews没有满，则每次新回收的ViewHolder放到mCachedViews中。如果mCachedViews已满，则新回收的ViewHolder放到mCachedViews的末尾，并移除mCachedViews中index=0 的ViewHolder到ViewPool中。