pull/6/head
yuanguangxin 4 years ago
parent eb2192f8c5
commit 95460a11c9

@ -0,0 +1,5 @@
<component name="ProjectCodeStyleConfiguration">
<state>
<option name="PREFERRED_PROJECT_CODE_STYLE" value="Default" />
</state>
</component>

@ -19,7 +19,8 @@
<select />
</component>
<component name="ChangeListManager">
<list default="true" id="af7ffdf2-4ddc-4ed6-8222-60ed5acbc2ed" name="Default Changelist" comment="update">
<list default="true" id="af7ffdf2-4ddc-4ed6-8222-60ed5acbc2ed" name="Default Changelist" comment="">
<change afterPath="$PROJECT_DIR$/.idea/codeStyles/codeStyleConfig.xml" afterDir="false" />
<change beforePath="$PROJECT_DIR$/.idea/workspace.xml" beforeDir="false" afterPath="$PROJECT_DIR$/.idea/workspace.xml" afterDir="false" />
</list>
<option name="SHOW_DIALOG" value="false" />
@ -27,6 +28,9 @@
<option name="HIGHLIGHT_NON_ACTIVE_CHANGELIST" value="false" />
<option name="LAST_RESOLUTION" value="IGNORE" />
</component>
<component name="CodeStyleSettingsInfer">
<option name="done" value="true" />
</component>
<component name="DatabaseView">
<option name="SHOW_INTERMEDIATE" value="true" />
<option name="GROUP_DATA_SOURCES" value="true" />
@ -52,6 +56,9 @@
<option name="RECENT_GIT_ROOT_PATH" value="$PROJECT_DIR$" />
<option name="UPDATE_TYPE" value="MERGE" />
</component>
<component name="ProjectCodeStyleSettingsMigration">
<option name="version" value="1" />
</component>
<component name="ProjectId" id="1VejAt63XWcMUQr7gJbMHyEoS6Q" />
<component name="ProjectLevelVcsManager" settingsEditedManually="true">
<ConfirmationsSetting value="2" id="Add" />
@ -619,7 +626,7 @@
<servers />
</component>
<component name="TypeScriptGeneratedFilesManager">
<option name="version" value="2" />
<option name="version" value="1" />
</component>
<component name="Vcs.Log.History.Properties">
<option name="COLUMN_ORDER">
@ -702,10 +709,10 @@
<screen x="0" y="0" width="1440" height="900" />
</state>
<state x="458" y="204" key="#com.intellij.refactoring.safeDelete.UnsafeUsagesDialog/0.0.1440.900@0.0.1440.900" timestamp="1587221348872" />
<state x="404" y="60" key="CommitChangelistDialog2" timestamp="1591633493160">
<screen x="0" y="0" width="1920" height="1080" />
<state x="303" y="50" key="CommitChangelistDialog2" timestamp="1592388288495">
<screen x="0" y="0" width="1440" height="900" />
</state>
<state x="303" y="50" key="CommitChangelistDialog2/0.0.1440.900@0.0.1440.900" timestamp="1588749779133" />
<state x="303" y="50" key="CommitChangelistDialog2/0.0.1440.900@0.0.1440.900" timestamp="1592388288495" />
<state x="404" y="60" key="CommitChangelistDialog2/0.0.1920.1080@0.0.1920.1080" timestamp="1591633493160" />
<state x="143" y="78" width="1152" height="720" key="DiffContextDialog" timestamp="1592386883631">
<screen x="0" y="0" width="1440" height="900" />
@ -800,10 +807,10 @@
</state>
<state x="378" y="207" width="683" height="486" key="find.popup/0.0.1440.900@0.0.1440.900" timestamp="1586846937826" />
<state x="504" y="248" width="911" height="584" key="find.popup/0.0.1920.1080@0.0.1920.1080" timestamp="1591635370753" />
<state x="479" y="282" key="git4idea.merge.GitPullDialog" timestamp="1592386874207">
<state x="479" y="282" key="git4idea.merge.GitPullDialog" timestamp="1592386920559">
<screen x="0" y="0" width="1440" height="900" />
</state>
<state x="479" y="282" key="git4idea.merge.GitPullDialog/0.0.1440.900@0.0.1440.900" timestamp="1592386874207" />
<state x="479" y="282" key="git4idea.merge.GitPullDialog/0.0.1440.900@0.0.1440.900" timestamp="1592386920559" />
<state x="638" y="338" key="git4idea.merge.GitPullDialog/0.0.1920.1080@0.0.1920.1080" timestamp="1591809009592" />
<state x="385" y="196" width="670" height="676" key="search.everywhere.popup" timestamp="1587219643331">
<screen x="0" y="0" width="1440" height="900" />

@ -172,7 +172,6 @@ SQL的执行顺序from---where--group by---having---select---order by
* undoLog 也就是我们常说的回滚日志文件 主要用于事务中执行失败进行回滚以及MVCC中对于数据历史版本的查看。由引擎层的InnoDB引擎实现,是逻辑日志,记录数据修改被修改前的值,比如"把id='B' 修改为id = 'B2' 那么undo日志就会用来存放id ='B'的记录”。当一条数据需要更新前,会先把修改前的记录存储在undolog中,如果这个修改出现异常,,则会使用undo日志来实现回滚操作,保证事务的一致性。当事务提交之后undo log并不能立马被删除,而是会被放到待清理链表中,待判断没有事物用到该版本的信息时才可以清理相应undolog。它保存了事务发生之前的数据的一个版本用于回滚同时可以提供多版本并发控制下的读MVCC也即非锁定读。
* redoLog 是重做日志文件是记录数据修改之后的值用于持久化到磁盘中。redo log包括两部分一是内存中的日志缓冲(redo log buffer),该部分日志是易失性的;二是磁盘上的重做日志文件(redo log file)该部分日志是持久的。由引擎层的InnoDB引擎实现,是物理日志,记录的是物理数据页修改的信息,比如“某个数据页上内容发生了哪些改动”。当一条数据需要更新时,InnoDB会先将数据更新然后记录redoLog 在内存中然后找个时间将redoLog的操作执行到磁盘上的文件上。不管是否提交成功我都记录你要是回滚了那我连回滚的修改也记录。它确保了事务的持久性。每个InnoDB存储引擎至少有1个重做日志文件组group每个文件组下至少有2个重做日志文件如默认的ib_logfile0和ib_logfile1。为了得到更高的可靠性用户可以设置多个的镜像日志组mirrored log groups将不同的文件组放在不同的磁盘上以此提高重做日志的高可用性。在日志组中每个重做日志文件的大小一致并以循环写入的方式运行。InnoDB存储引擎先写重做日志文件1当达到文件的最后时会切换至重做日志文件2再当重做日志文件2也被写满时会再切换到重做日志文件1中。
* MVCC多版本并发控制是MySQL中基于乐观锁理论实现隔离级别的方式用于读已提交和可重复读取隔离级别的实现。在MySQL中会在表中每一条数据后面添加两个字段最近修改该行数据的事务ID指向该行undolog表中回滚段的指针。Read View判断行的可见性创建一个新事务时copy一份当前系统中的活跃事务列表。意思是当前不应该被本事务看到的其他事务id列表。已提交读隔离级别下的事务在每次查询的开始都会生成一个独立的ReadView,而可重复读隔离级别则在第一次读的时候生成一个ReadView之后的读都复用之前的ReadView。
* binlog由Mysql的Server层实现,是逻辑日志,记录的是sql语句的原始逻辑比如"把id='B' 修改为id = B2。binlog会写入指定大小的物理文件中,是追加写入的,当前文件写满则会创建新的文件写入。 产生:事务提交的时候,一次性将事务中的sql语句,按照一定的格式记录到binlog中。用于复制和恢复在主从复制中从库利用主库上的binlog进行重播(执行日志中记录的修改逻辑),实现主从同步。业务数据不一致或者错了用binlog恢复。
### binlog和redolog的区别
@ -740,29 +739,6 @@ Kafka最初考虑的问题是customer应该从brokes拉取消息还是brokers
4. 信号量:不能传递复杂消息,只能用来同步。
5. 共享内存区:能够很容易控制容量,速度快,但要保持同步,比如一个进程在写的时候,另一个进程要注意读写的问题,相当于线程中的线程安全,当然,共享内存区同样可以用作线程间通讯,不过没这个必要,线程间本来就已经共享了同一进程内的一块内存。
### 内存管理有哪几种方式
1. 块式管理把主存分为一大块、一大块的当所需的程序片断不在主存时就分配一块主存空间把程序片断load入主存就算所需的程序片度只有几个字节也只能把这一块分配给它。这样会造成很大的浪费平均浪费了50的内存空间但是易于管理。
2. 页式管理:把主存分为一页一页的,每一页的空间要比一块一块的空间小很多,显然这种方法的空间利用率要比块式管理高很多。
3. 段式管理:把主存分为一段一段的,每一段的空间又要比一页一页的空间小很多,这种方法在空间利用率上又比页式管理高很多,但是也有另外一个缺点。一个程序片断可能会被分为几十段,这样很多时间就会被浪费在计算每一段的物理地址上。
4. 段页式管理结合了段式管理和页式管理的优点。将程序分成若干段每个段分成若干页。段页式管理每取一数据要访问3次内存。
### 页面置换算法
1. 最佳置换算法OPT只具有理论意义的算法用来评价其他页面置换算法。置换策略是将当前页面中在未来最长时间内不会被访问的页置换出去。
2. 先进先出置换算法FIFO简单粗暴的一种置换算法没有考虑页面访问频率信息。每次淘汰最早调入的页面。
3. 最近最久未使用算法LRU算法赋予每个页面一个访问字段用来记录上次页面被访问到现在所经历的时间t每次置换的时候把t值最大的页面置换出去(实现方面可以采用寄存器或者栈的方式实现)。
4. 时钟算法clock(也被称为是最近未使用算法NRU)页面设置一个访问位并将页面链接为一个环形队列页面被访问的时候访问位设置为1。页面置换的时候如果当前指针所指页面访问为为0那么置换否则将其置为0循环直到遇到一个访问为位0的页面。
5. 改进型Clock算法在Clock算法的基础上添加一个修改位替换时根究访问位和修改位综合判断。优先替换访问位和修改位都是0的页面其次是访问位为0修改位为1的页面。
6. LFU最少使用算法LFU设置寄存器记录页面被访问次数每次置换的时候置换当前访问次数最少的。
### 操作系统中进程调度策略有哪几种
1. 先来先服务调度算法FCFS队列实现非抢占先请求CPU的进程先分配到CPU可以作为作业调度算法也可以作为进程调度算法按作业或者进程到达的先后顺序依次调度对于长作业比较有利.
2. 最短作业优先调度算法SJF作业调度算法算法从就绪队列中选择估计时间最短的作业进行处理直到得出结果或者无法继续执行平均等待时间最短但难以知道下一个CPU区间长度缺点不利于长作业未考虑作业的重要性运行时间是预估的并不靠谱.
3. 优先级调度算法(可以是抢占的,也可以是非抢占的)优先级越高越先分配到CPU相同优先级先到先服务存在的主要问题是低优先级进程无穷等待CPU会导致无穷阻塞或饥饿.
4. 时间片轮转调度算法(可抢占的)按到达的先后对进程放入队列中然后给队首进程分配CPU时间片时间片用完之后计时器发出中断暂停当前进程并将其放到队列尾部循环 ;队列中没有进程被分配超过一个时间片的CPU时间除非它是唯一可运行的进程。如果进程的CPU区间超过了一个时间片那么该进程就被抢占并放回就绪队列。
### 死锁的4个必要条件
1. 互斥条件:一个资源每次只能被一个线程使用;
@ -794,15 +770,7 @@ Kafka最初考虑的问题是customer应该从brokes拉取消息还是brokers
4. 服务端响应HTTP响应报文报文由状态行status line、相应头部headers、空行blank line和响应数据response body4个部分组成。
5. 浏览器解析渲染
### 计算机网络的五层模型
1. 应用层:为操作系统或网络应用程序提供访问网络服务的接口 通过应用进程间的交互完成特定网络应用。应用层定义的是应用进程间通信和交互的规则。HTTPFTPSMTPRPC
2. 传输层负责向两个主机中进程之间的通信提供通用数据服务。TCP,UDP
3. 网络层负责对数据包进行路由选择和存储转发。IPICMP(ping命令)
4. 数据链路层两个相邻节点之间传送数据时数据链路层将网络层交下来的IP数据报组装成帧在两个相邻的链路上传送帧frame)。每一帧包括数据和必要的控制信息。
5. 物理层物理层所传数据单位是比特bit)。物理层要考虑用多大的电压代表1 或 0 ,以及接受方如何识别发送方所发送的比特。
### tcp和 udp区别
### tcp和udp区别
1. TCP面向连接UDP是无连接的即发送数据之前不需要建立连接。
2. TCP提供可靠的服务。也就是说通过TCP连接传送的数据无差错不丢失不重复且按序到达;UDP尽最大努力交付即不保证可靠交付。
@ -811,7 +779,7 @@ Kafka最初考虑的问题是customer应该从brokes拉取消息还是brokers
5. TCP首部开销20字节UDP的首部开销小只有8个字节。
6. TCP的逻辑通信信道是全双工的可靠信道UDP则是不可靠信道。
### tcp和 udp的优点
### tcp和udp的优点
* TCP的优点 可靠,稳定 TCP的可靠体现在TCP在传递数据之前会有三次握手来建立连接而且在数据传递时有确认、窗口、重传、拥塞控制机制在数据传完后还会断开连接用来节约系统资源。 TCP的缺点 慢,效率低,占用系统资源高,易被攻击 TCP在传递数据之前要先建连接这会消耗时间而且在数据传递时确认机制、重传机制、拥塞控制机制等都会消耗大量的时间而且要在每台设备上维护所有的传输连接事实上每个连接都会占用系统的CPU、内存等硬件资源。 而且因为TCP有确认机制、三次握手机制这些也导致TCP容易被人利用实现DOS、DDOS、CC等攻击。
* UDP的优点比TCP稍安全 UDP没有TCP的握手、确认、窗口、重传、拥塞控制等机制UDP是一个无状态的传输协议所以它在传递数据时非常快。没有TCP的这些机制UDP较TCP被攻击者利用的漏洞就要少一些。但UDP也是无法避免攻击的比如UDP Flood攻击…… UDP的缺点 不可靠,不稳定 因为UDP没有TCP那些可靠的机制在数据传递时如果网络质量不好就会很容易丢包。 基于上面的优缺点,那么: 什么时候应该使用TCP 当对网络通讯质量有要求的时候比如整个数据要准确无误的传递给对方这往往用于一些要求可靠的应用比如HTTP、HTTPS、FTP等传输文件的协议POP、SMTP等邮件传输的协议。 在日常生活中常见使用TCP协议的应用如下 浏览器用的HTTP FlashFXP用的FTP Outlook用的POP、SMTP Putty用的Telnet、SSH QQ文件传输。什么时候应该使用UDP 当对网络通讯质量要求不高的时候要求网络通讯速度能尽量的快这时就可以使用UDP。 比如日常生活中常见使用UDP协议的应用如下 QQ语音 QQ视频 TFTP。
@ -867,50 +835,7 @@ void quick_sort(int a[], int low, int high){
}
```
5. 堆排序将待排序序列构造成一个大顶堆此时整个序列的最大值就是堆顶的根节点。将其与末尾元素进行交换此时末尾就为最大值。然后将剩余n-1个元素重新构造成一个堆这样会得到n个元素的次小值。如此反复执行便能得到一个有序序列了。
```java
public class Test {
public void sort(int[] arr) {
for (int i = arr.length / 2 - 1; i >= 0; i--) {
adjustHeap(arr, i, arr.length);
}
for (int j = arr.length - 1; j > 0; j--) {
swap(arr, 0, j);
adjustHeap(arr, 0, j);
}
}
public void adjustHeap(int[] arr, int i, int length) {
int temp = arr[i];
for (int k = i * 2 + 1; k < length; k = k * 2 + 1) {
if (k + 1 < length && arr[k] < arr[k + 1]) {
k++;
}
if (arr[k] > temp) {
arr[i] = arr[k];
i = k;
} else {
break;
}
}
arr[i] = temp;
}
public void swap(int[] arr, int a, int b) {
int temp = arr[a];
arr[a] = arr[b];
arr[b] = temp;
}
public static void main(String[] args) {
int[] arr = {9, 8, 7, 6, 5, 4, 3, 2, 1};
new Test().sort(arr);
System.out.println(Arrays.toString(arr));
}
}
```
5. 堆排序假设序列有n个元素,先将这n建成大顶堆然后取堆顶元素与序列第n个元素交换然后调整前n-1元素使其重新成为堆然后再取堆顶元素与第n-1个元素交换再调整前n-2个元素...直至整个序列有序。
6. 希尔排序:先将整个待排记录序列分割成为若干子序列分别进行直接插入排序,待整个序列中的记录基本有序时再对全体记录进行一次直接插入排序。
7. 归并排序:把有序表划分成元素个数尽量相等的两半,把两半元素分别排序,两个有序表合并成一个

Loading…
Cancel
Save