Android春招一面面试题Shopee

发布于:2021-11-29 10:14:16

Android春招面试题Shopee

数据库的事务?


事务就是对数据库操作的序列,是一个不可分割的工作单位,这个序列中的操作或者全部执行,或者全部不执行;

特性:原子性/持久性/一致性/隔离性


原子性:或者全部执行或者全部不执行,如转账时要么同时成功要么同时失败;

一致性:是指事务开始之前和事务结束之后,不能破坏关系数据的完整性和业务逻辑的一致性;如转账时保证钱的总数是不变的;

持久性:当提交后,对数据库的改变是通就行的,不会被回滚;

隔离性:多个事务并发执行时,相互之间无影响;


如在多用户,多并发的情况下,多个事务对用一个数据进行访问时,只能看到这个数据在上一个事务修改前的状态或者修改后的状态,不会看到中间状态的数据;

事务之间相互影响的种类


脏读

不可重复读

幻读

丢失更新

url到网页渲染出来经历了哪些步骤?


根据请求的url交给DNS域名解析,找到真实的IP,向服务器发起请求;

服务器交给后台处理完后返回数据,浏览器接收数据(HTML/CSS/JS/图像等);

浏览器对数据进行解析,建立起相应的内部结构;

载入解析到的资源文件,渲染页面,完成;

网络中的滑动窗口和拥塞控制


滑动窗口:实现对TCP传输速率的控制,本质上就是流量控制,也是保证可靠传输的方法之一;

拥塞控制是指网络资源大于可用资源;目前的解决方法:


慢启动

拥塞避免

快重传

快恢复

Https为什么安全,TLS


HTTPS就是在HTTP与TCP中间加多了一层加密层TLS/SSL;HTTP将数据给到加密层,数据加密后,再给到TCP进行传输;

SSL是个加密套件,为了解决传输内容会被查看和修改;TLS是SSL的标准版

乐观锁和悲观锁


乐观锁:总是假设每次去拿数据的时候都认别的线程不会修改,不会上锁,在更新时候去判断,社用于多读的应用类型,可提高吞吐量;如数据库的write_condition就是乐观锁;

悲观锁:每次拿数据的时候都会上锁,共享资源每次只给一个线程使用,其他线程阻塞,用完后再把资源让给其他线程;

HashMap的插入操作?如果多次扩容之后如何解决内存资源的浪费?


HashMap的底层原理?


往HashMap中put元素时,根据key的hash值得到Entry元素在数组中的位置,然后把这个Entry元素放在相应的位置( 即下标),如果这个位置上有其他元素就在同一个位置的Entry元素以链表的形式存放,新加入的放在链表头;

之所以这么设计是因为数据存储是连续的,占用内存严重,但是随机查找会快,因此寻址简单而插入删除困难,而链表

从HashMap中get元素时先计算key的hashcode,找到数组中对应位置,然后通过key的equals方法在对应位置的链表中找到需要的Entry元素,所以HashMap的数据结构是数组和链表的组合,此外HashMap中的key和value都允许为null,key为null的键值对都放在头结点的链表中;

HashMap默认的初始化长度为多少?扩容?


JDK中默认长度为16(Android SDK中为4) , 并且默认长度和扩容后的长度都必须是2的幂;

?

view中的onDraw的步骤


对视图的背景进行绘制


会根据layout过程确认的视图位置来设置背景的绘制区域;

调用Drawable的draw方法来完成背景的绘制工作;

对视图的内容进行绘制

对当前视图的子视图进行绘制;

对试图的滚动条进行绘制

TCP三次握手的过程?为什么要三次握手?tcp为什么可靠?


tcp连接握手是用于传输通信双方的数据原点的序列号,同时tcp是全双工的一个双向通信,为了可靠传输,始终都需要同步信号.出事双方的序号是随机的.刚开始通信双方都产生一个初始的随机序列号ISN;

三次握手的过程:


第一次握手:建立连接时,客户端发送syn(同步序列编号)包到服务器,并进入SYN_SEND状态,等待服务器确认;

第二次握手:服务器收到syn包,必须确认客户端的SYN,命名为ACK,同时自己也发送一个SYN包,即SYN+ACK包,此时服务器进入SYN_RECV状态;

第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确*麬CK,发送完毕后,客户端和服务器进入ESTABLISHED状态,完成三次握手;

为什么两次不行?


为了数据传输,TCP协议的通信双方都必须维护一个序列号,三次握手的过程即通信双方互相告知序列号起始值的过程;没有第三步的同步信号,不知道双方是否达成一致的状态

tcp采用了确认应答机制,即发送数据之后必须收到确认消息,才算一次有效的传输;

相关推荐

最新更新

猜你喜欢