温州建设网站公司,广州黄埔网站建设,步骤英文,北京中企动力怎么样1.说一说ArrayList的实现原理#xff1f; ArrayList底层基于数组实现#xff0c;内部封装了Object类型的数组#xff0c;实现了list接口#xff0c;通过默认构造器创建容器时#xff0c;该数组被初始化为一个空数组#xff0c;首次添加数据时再将其初始化为容量为10的数组…1.说一说ArrayList的实现原理 ArrayList底层基于数组实现内部封装了Object类型的数组实现了list接口通过默认构造器创建容器时该数组被初始化为一个空数组首次添加数据时再将其初始化为容量为10的数组也可以通过有参构造器显式指定数组长度当添加的数据超出数组长度时触发自动扩容将旧数据拷贝到新数组中新数组为旧数组的1.5倍相对于同为继承list的LinkedList来说查询快增改删较慢则LinkedList相反。 2.Java中有哪些集合类 Java中的集合类分为4大类分别由4个接口来代表它们是Set、List、Queue、Map。其中Set、List、Queue、都继承自Collection接口。
· Set代表无序的、元素不可重复的集合。
· List代表有序的、元素可以重复的集合。
· Queue代表先进先出FIFO的队列。
· Map代表具有映射关系key-value的集合。 Java提供了众多集合的实现类它们都是这些接口的直接或间接的实现类其中比较常用的有HashSet、TreeSet、ArrayList、LinkedList、ArrayDeque、HashMap、TreeMap等。 3.如何打开一个大文件 打开大文件的关键在于不能直接将文件中的数据全部读取到内存中以免引发OOM。重点要考虑内存的利用问题就是如何使用较小的内存空间来解决问题。可以考虑的方式是每次读取文件中的一部分内容分多次处理这个文件具体还要看打开文件的目的。
如果我们打开的是文本文件期望读取甚至分析该文件中的内容则可以采用java.util.Scanner来逐行读取文件的内容。在Scanner遍历文件的过程中每处理一行之后我们都要丢弃对该行的引用以节约内存。如果我们打开的是字节文件期望拷贝或者搬运该文件中的内容则可以采用缓冲流或NIO。每次利用缓冲区处理文件中的一小段数据这样在处理过程中使用的内存空间便是很有限的不会造成内存溢出的问题。 4.如何让UDP协议变得可靠 UDP它不属于连接型协议因而具有资源消耗小处理速度快的优点所以通常音频、视频和普通数据在传送时使用UDP较多因为它们即使偶尔丢失一两个数据包也不会对接收结果产生太大影响。 传输层无法保证数据的可靠传输只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式只是实现不在传输层实现转移到了应用层。 实现确认机制、重传机制、窗口确认机制。 如果你不利用linux协议栈以及上层socket机制自己通过抓包和发包的方式去实现可靠性传输那么必须实现如下功能 发送包的分片、包确认、包的重发 接收包的调序、包的序号确认 目前有如下开源程序利用udp实现了可靠的数据传输。分别为RUDP、RTP、UDT。
1RUDP RUDP 提供一组数据服务质量增强机制如拥塞控制的改进、重发机制及淡化服务器算法等从而在包丢失和网络拥塞的情况下 RTP 客户机实时位置面前呈现的就是一个高质量的 RTP 流。在不干扰协议的实时特性的同时可靠 UDP 的拥塞控制机制允许 TCP 方式下的流控制行为。
2RTP 实时传输协议RTP为数据提供了具有实时特征的端对端传送服务如在组播或单播网络服务下的交互式视频音频或模拟数据。应用程序通常在 UDP 上运行 RTP 以便使用其多路结点和校验服务这两种协议都提供了传输层协议的功能。但是 RTP 可以与其它适合的底层网络或传输协议一起使用。如果底层网络提供组播方式那么 RTP 可以使用该组播表传输数据到多个目的地。 RTP 本身并没有提供按时发送机制或其它服务质量QoS保证它依赖于底层服务去实现这一过程。 RTP 并不保证传送或防止无序传送也不确定底层网络的可靠性。 RTP 实行有序传送 RTP 中的序列号允许接收方重组发送方的包序列同时序列号也能用于决定适当的包位置例如在视频解码中就不需要顺序解码。
3UDT 基于UDP的数据传输协议UDP-basedData Transfer Protocol简称UDT是一种互联网数据传输协议。UDT的主要目的是支持高速广域网上的海量数据传输而互联网上的标准数据传输协议TCP在高带宽长距离网络上性能很差。顾名思义UDT建于UDP之上并引入新的拥塞控制和数据可靠性控制机制。UDT是面向连接的双向的应用层协议。它同时支持可靠的数据流传输和部分可靠的数据报传输。由于UDT完全在UDP上实现它也可以应用在除了高速数据传输之外的其它应用领域例如点到点技术P2P防火墙穿透多媒体数据传输等等。
5.HTTP协议的请求方式有哪些
方法描述是否包含主体GET从服务器获取一份文档否HEAD只从服务器获取文档的首部 否POST向服务器发送带要处理的数据 是PUT将请求的主体部分存储在服务器上是TRACE对可能经过代理服务器传送到服务器上去的报文进行追踪否OPTIONS决定可以在服务器上执行哪些方法否DELETE从服务器上删除一份文档否 6.InnoDB中的行级锁是怎么实现的 InnoDB行锁是通过给索引上的索引项加锁来实现的只有通过索引条件检索数据InnoDB才使用行级锁否则InnoDB将使用表锁。 7.说一说你对Spring IoC的理解 spring ioc是spring两大核心之一spring为我们提供了一个ioc容器也就是beanFactory同时ioc有个非常强大的功能叫做di也就是依赖注入我们可以通过配置或者xml文件的方式将bean所依赖的对象通过name名字或者type类别注入进这个beanFactory中正因为这个依赖注入实现类与依赖类之间的解耦如果在一个复杂的系统中类之间的依赖关系特别复杂首先这非常不利于后期代码的维护ioc就很好的帮助我们解决了这个问题它帮助我们维护了类与类之间的依赖关系降低了耦合性使我们的类不需要强依赖于某个类而且在spring容器启动的时候spring容器会帮助我们自动的创建好所有的bean这样我们程序运行的过程中就不需要花费时间去创建这些bean速度就快了许多。 8.HTTPS协议如何保证整个传输过程安全 HTTP 存在的问题 1. 窃听
第三方劫持请求后可以获取通信内容。对于一些敏感数据这是不被允许的。
2. 篡改
第三方劫持请求后可以篡改通信内容。例如银行系统中张三本来要给李四转账第三方劫持请求后篡改了请求数据将收款方改为自己导致用户资金流失。
3. 冒充
第三方可以冒充客户端发送数据。由于是明文传输没有「加签/验签」操作服务端无法保证请求来源的合法性。 8.1 防窃听加密
8.1.1 对称加密 采用单钥密码系统的加密方法同一个密钥可以同时用作信息的加密和解密这种加密方法称为对称加密也称为单密钥加密。
例如 DES 就是一种对称加密算法甲乙双方约定一个密钥「Key」双方发送数据前都用该密钥对数据进行加密传输收到数据后再解密成明文即可。这种方式只要保证密钥不被泄漏理论上也是安全的。 但是这会带来一个新的问题密钥如何保存
对于 PC 端来说浏览器页面是明文的肯定不能存储密钥。对于 iOS/Android 来说即使把密钥藏在安装包的某个位置也很容易被第三方拆包破解。
既然客户端保存不靠谱那么密钥只在服务端保存客户端去向服务端拿密钥是否可行
依然不可行服务端要怎么把密钥给你呢明文肯定不行如果要加密又要用到密钥 B密钥 B 的传输又要用到密钥 C如此循环无解。 8.1.2 非对称加密 非对称加密算法需要两个密钥公开密钥publickey:简称公钥和私有密钥privatekey:简称私钥。公钥与私钥是一对如果用公钥对数据进行加密只有用对应的私钥才能解密。因为加密和解密使用的是两个不同的密钥所以这种算法叫作非对称加密算法。
甲乙双方各有一套自己的密钥对互相公开彼此的公钥当甲方要发送数据给乙方时用乙方公钥加密这样密文就只有乙方自己能解开了就算请求被劫持第三方拿到了数据由于没有乙方的私钥也无法解密这样就保证了数据被窃听。
单向非对称加密
绝大多数互联网网站对外是完全公开的所有人都可以访问服务端没必要验证所有客户端的合法性只有客户端需要验证服务端的合法性。例如用户在访问电商网站时必须确保不是钓鱼网站以防资金损失。
这种情况下只需要单向加密即可。服务端发送给客户端的一般不会有敏感信息明文传输即可。但是客户端发送给服务端的就很有可能是敏感信息例如用户修改密码这时就必须加密传输了。 双向非对称加密
有时服务端也需要验证客户端的合法性例如银行系统。由于涉及到金钱因此系统必须设计的足够安全。除了客户端发送给服务端的数据是加密的服务端发送给客户端的数据也必须加密。
怎么做的呢一般银行会给用户一个 U 盘里面存储的就是一套密钥对客户端告诉服务端自己的公钥服务端根据公钥加密后再传输给客户端。 8.2 防篡改加签
通过非对称加密的密文传输可以防止数据被窃听但是如果存在这种场景呢
张三登陆银行系统要给李四转一笔钱数据通过服务端的公钥 PubB 加密传输但是第三方劫持了这个请求篡改了报文数据写入的是「给王五转钱」因为服务端的公钥是公开的谁都能拿到因此第三方也可以正常加密传输服务端正常解密后进行了错误的操作导致用户资金流失。 对于涉及到资金的操作服务端必须要验证数据的合法性确保数据没有被篡改这就需要客户端对数据进行加签了。
非对称加密除了可以「公钥加密私钥解密」外还可以「私钥加签公钥验签」。
银行给用户一个 U 盘里面有一套密钥对。客户端在发送转账请求前先对请求体加签得到签名「sign」然后再用服务端公钥加密得到密文「data」客户端将签名和密文一起发送给服务端服务端解密后还需要用客户端的公钥对「sign」进行验签只有验签通过才能进行后续操作否则就是非法请求了。 这样即使请求被第三方劫持了第三方可以篡改数据但是签名它改不了服务端解密后会发现数据和「sign」对不上说明数据是被篡改过的。 8.3 防冒充证书
通过加密防止数据被窃听通过加签防止数据被篡改现在看来好像已经很安全了但是别忘了有个前提是公钥的传输是安全的。不幸的是公钥的安全传输很难保证。
中间人攻击 假设存在这样一种场景客户端和服务端想互换公钥但是请求都被一个中间人劫持了结果就是服务端和客户端以为是和双方互换公钥了结果是客户端和服务端都和中间人互换公钥了。 一旦出现这种问题就非常严重前面讲到的加密解密、加签验签都失效了。客户端以为中间人就是服务端服务端以为中间人就是客户端双方以为是在和对方通信其实都是在和中间人通信中间人可以随意的窃听和篡改数据。
这个问题之所以会出现就是因为公钥的传输是不安全的。客户端和服务端之间互换公钥时如何确保公钥就是对方发出的没有被篡改过呢 8.3.1 数字证书与认证中心
在之前的基础上引入一个中间角色证书认证中心 CA。当服务端要把公钥发送给客户端时不是直接发送公钥而是先把公钥发送给 CACA 根据公钥生成一份「证书」给到服务端服务端将证书给客户端。客户端拿到证书后去 CA 验证证书的合法性确保证书是服务端下发的。
CA 就类似于「公证处」也是一台服务器它自己本身也有一套密钥对。它的工作就是根据服务端的公钥生成证书然后帮助客户端来验证证书的合法性。 8.3.2 CA 被冒充怎么办
引入 CA 可以保证公钥的传输安全但是有一个前提客户端和服务端是信任 CA 的也就是说 CA 必须是安全可信任的如果 CA 被冒充就又会出现上面的问题。 基于这个问题就引入了「根证书」和「CA 信任链」的概念。
要让客户端和服务端信任 CA其实 CA 也面临着同样的问题那就是如何保证 CA 的公钥是安全不被篡改的答案也是一样的就是给 CA 也颁发证书那这个证书由谁来颁发呢自然是 CA 的上一级 CA 了。CA 的上一级 CA 如何保证安全那就 CA 的上一级 CA 的上一级 CA 给它办法证书了。最终就会形成一个证书信用链如下 客户端要想验证服务器的 C3 证书是否合法会跑去 CA2 验证要验证 CA2 就去 CA1 验证以此类推。对于根证书是没法验证的只能无条件相信。因为 Root CA 都是国际上公认的机构一般用户的操作系统或浏览器在发布时就会在里面嵌入这些机构的 Root 证书。
如下是百度官网的证书点击浏览器地址栏旁边的锁标识就能看到了。 8.4 SSL/TLS 四次握手
了解了底层的实现加密、加签、证书等概念后再来看 SSL/TLS 协议就很容易理解了。SSL/TLS 需要四次握手的过程
客户端向服务端所有证书。服务端发送证书。客户端验证证书提取公钥发送对称加密的密钥。服务端收到密钥响应 OK。 8.5 再看 HTTPS
了解 SSL/TLS再回过头来看 HTTPS 就很简单了HTTPSHTTPSSL/TLS。
使用 HTTPS 进行通信时先是建立传输层 TCP 的连接完成三次握手然后再是 SSL/TLS 协议的四次握手双方协商出对称加密的密钥之后的通信数据会利用该密钥进行加密传输。 HTTP1.1 开始支持长连接了只要连接不关闭七次握手只需要执行一次性能损耗不会太大而且数据传输采用的是对称加密相比于非对称加密性能损耗也小得多。因此 HTTPS 相比于 HTTP性能会有一定影响但不会太大相比之下数据传输安全显得更加重要 9.说一说HashMap的实现原理
众所周知HashMap是一个用于存储Key-Value键值对的集合每一个键值对也叫做Entry包括Key-Value其中Key 和 Value 允许为null。这些个键值对Entry分散存储在一个数组当中这个数组就是HashMap的主干。另外HashMap数组每一个元素的初始值都是Null。 值得注意的是HashMap不能保证映射的顺序插入后的数据顺序也不能保证一直不变如扩容后rehash。
要说HashMap的原理首先要先了解它的数据结构 如上图为JDK1.8版本的数据结构其实HashMap在JDK1.7及以前是一个“链表散列”的数据结构即数组 链表的结合体。JDK8优化为数组链表红黑树。
我们常把数组中的每一个节点称为一个桶。当向桶中添加一个键值对时首先计算键值对中key的hash值hash(key)以此确定插入数组中的位置即哪个桶但是可能存在同一hash值的元素已经被放在数组同一位置了这种现象称为碰撞这时按照尾插法(jdk1.7及以前为头插法)的方式添加key-value到同一hash值的元素的最后面链表就这样形成了。
当链表长度超过8(TREEIFY_THRESHOLD - 阈值)时链表就自行转为红黑树。
注意同一hash值的元素指的是key内容一样么不是。根据hash算法的计算方式是将key值转为一个32位的int值近似取值key值不同但key值相近的很可能hash值相同如key“a”和key“aa”等 10.HTTP超文本传输协议是什么 Http是超文本传输协议它是应用层的面向对象的协议它是基于TCP/IP的高级协议默认端口号是80。它是基于请求响应模型的即一次请求对应一次响应。它是无状态的每次请求之间相互独立。HTTP协议请求消息的数据格式为请求行请求头请求空行和请求体。请求行中主要包括请求方式请求url请求协议和版本等。请求方式在HTTP协议中有7种最常用的有2中get和post。如果是get请求则还会把请求参数拼接到url后请求头是客户端浏览器想要告诉浏览器的一些信息如user-Agent浏览器信息host主机地址reference请求来源等。请求空行是用来分割请求头和请求体的请求体是post请求下封装请求参数的。
