Reset

reset 的本质：移动 HEAD 以及它所指向的 branch

实质上，reset 这个指令虽然可以用来撤销 commit ，但它的实质行为并不是撤销，而是移动 HEAD ，并且「捎带」上 HEAD 所指向的 branch（如果有的话）。也就是说，reset 这个指令的行为其实和它的字面意思 “reset“（重置）十分相符：它是用来重置 HEAD 以及它所指向的 branch 的位置的。

而 reset –hard HEAD^ 之所以起到了撤销 commit 的效果，是因为它把 HEAD 和它所指向的 branch 一起移动到了当前 commit 的父 commit 上，从而起到了「撤销」的效果：

git reset

Git 的历史只能往回看，不能向未来看，所以把 HEAD 和 branch 往回移动，就能起到撤回 commit 的效果。

所以同理，reset –hard 不仅可以撤销提交，还可以用来把 HEAD 和 branch 移动到其他的任何地方。

1

git reset --hard branch2

git reset –hard branch2

reset三种模式区别和使用场景

区别：

1. –hard：重置位置的同时，直接将 working Tree工作目录、 index 暂存区及 repository 都重置成目标Reset节点的內容,所以效果看起来等同于清空暂存区和工作区。
2. –soft：重置位置的同时，保留working Tree工作目录和index暂存区的内容，只让repository中的内容和 reset 目标节点保持一致，因此原节点和reset节点之间的【差异变更集】会放入index暂存区中(Staged files)。所以效果看起来就是工作目录的内容不变，暂存区原有的内容也不变，只是原节点和Reset节点之间的所有差异都会放到暂存区中。
3. –mixed（默认）：重置位置的同时，只保留Working Tree工作目录的內容，但会将 Index暂存区 和 Repository 中的內容更改和reset目标节点一致，因此原节点和Reset节点之间的【差异变更集】会放入Working Tree工作目录中。所以效果看起来就是原节点和Reset节点之间的所有差异都会放到工作目录中。

使用场景:

1. –hard 要放弃目前本地的所有改变時，即去掉所有add到暂存区的文件和工作区的文件，可以执行 git reset -hard HEAD 来强制恢复git管理的文件夹的內容及状态；(2) 真的想抛弃目标节点后的所有commit**（可能觉得目标节点到原节点之间的commit提交都是错了，之前所有的commit有问题）。

2. –soft：原节点和reset节点之间的【差异变更集】会放入index暂存区中(Staged files)，所以假如我们之前工作目录没有改过任何文件，也没add到暂存区，那么使用reset –soft后，我们可以直接执行 git commit 將 index暂存区中的內容提交至 repository 中。为什么要这样呢？这样做的使用场景是：假如我们想合并「当前节点」与「reset目标节点」之间不具太大意义的 commit 记录(可能是阶段性地频繁提交,就是开发一个功能的时候，改或者增加一个文件的时候就commit，这样做导致一个完整的功能可能会好多个commit点，这时假如你需要把这些commit整合成一个commit的时候)時，可以考虑使用reset –soft来让 commit 演进线图较为清晰。总而言之，可以使用–soft合并commit节点。

3. –mixed（默认）：

   使用完reset –mixed后，我們可以直接执行 git add 将這些改变果的文件內容加入 index 暂存区中，再执行 git commit 将 Index暂存区 中的內容提交至Repository中，这样一样可以达到合并commit节点的效果（与上面–soft合并commit节点差不多，只是多了git add添加到暂存区的操作）

   移除所有Index暂存区中准备要提交的文件(Staged files)，我们可以执行 git reset HEAD 来 Unstage 所有已列入 Index暂存区 的待提交的文件。(有时候发现add错文件到暂存区，就可以使用命令)。

   commit提交某些错误代码，或者没有必要的文件也被commit上去，不想再修改错误再commit（因为会留下一个错误commit点），可以回退到正确的commit点上，然后所有原节点和reset节点之间差异会返回工作目录，假如有个没必要的文件的话就可以直接删除了，再commit上去就OK了。

第一步

1
2
3
4
5
6
7

#include <stdio.h>
int main()
{
   /* 我的第一个 C 程序 */
   printf("Hello, World! \n");
   return 0;
}

1. 打开一个文本编辑器，添加上述代码。
2. 保存文件为 hello.c。
3. 打开命令提示符，进入到保存文件所在的目录。
4. 键入 gcc hello.c，输入回车，编译代码。
5. 如果代码中没有错误，命令提示符会跳到下一行，并生成 a.out 可执行文件。
6. 现在，键入 a.out 来执行程序。
7. 您可以看到屏幕上显示 “Hello World”。

1
2
3

$ gcc hello.c
$ ./a.out
Hello, World!

Socket传输的定义和其特点

所谓socket通常也称作”套接字”,实现服务器和客户端之间的物理连接，并进行数据传输，主要有UDP和TCP两个协议。Socket处于网络协议的传输层。

• UDP协议：广播式数据传输，不进行数据验证
• TCP协议：传输控制协议，一种面向连接的协议，给用户进程提供可靠的全双工的字节流，

在三次握手发送的数据包中有两个ACK值（Acknowledgement），人们习惯一个大写，一个小写来加以区分。最近Linux运维班的老师在讲网络基础知识的时候又讲到了三次握手四次断开。我在听课的时候总是感觉这两个大小写的ACK和我以前学习网络时候理解的大小写是反着的。课余时间我就在网上查了一下这方面的资料，却看到貌似关于哪个大写哪个小写非常混乱。这样有时就会把刚学习三次握手的新手搞的晕头转向，分不清到底哪个是哪个了。
其实ACK也好，ack也好，只不过是个代号而已，叫他张三也行，叫他李四也没事，没有任何影响，因为咱们不会改动那个东西。就算是把名字记反了，对咱们也没有任何影响，大家知道三次握手的数据包里有这么两个东西就行了。
一个是确认值(Acknowledgement)，为1便是确认连接。
另一个是确认编号(Acknowledgement Number)，即接收到的上一次远端主机传来的seq然后+1，再发送给远端主机。提示远端主机已经成功接收上一次所有数据。

我们说到keepalive的时候，需要先明确一点，这个keepalive说的是tcp的还是http的。

tcp的keepalive是侧重在保持客户端和服务端的连接，一方会不定期发送心跳包给另一方，当一方端掉的时候，没有断掉的定时发送几次心跳包，如果间隔发送几次，对方都返回的是RST，而不是ACK，那么就释放当前链接。设想一下，如果tcp层没有keepalive的机制，一旦一方断开连接却没有发送FIN给另外一方的话，那么另外一方会一直以为这个连接还是存活的，几天，几月。那么这对服务器资源的影响是很大的。

http的keep-alive一般我们都会带上中间的横杠，普通的http连接是客户端连接上服务端，然后结束请求后，由客户端或者服务端进行http连接的关闭。下次再发送请求的时候，客户端再发起一个连接，传送数据，关闭连接。这么个流程反复。但是一旦客户端发送connection:keep-alive头给服务端，且服务端也接受这个keep-alive的话，两边对上暗号，这个连接就可以复用了，一个http处理完之后，另外一个http数据直接从这个连接走了。

本文主要以下几个方面详细介绍了CategoryVS.Extension的用法及实现原理先，先给出结论，我们后续文章详细解释。

• 形式上来看，extension是匿名的category。

• Extension里声明的方法需要在.m文件的@implementation中实现，Category不强制要求。

• Extension可以添加属性（变量），Category不可以。

本文从以下几个方面来分析iOS系统的APP的启动流程，以及我们在优化启动时间时应该在哪些方面入手

• 专业术语解释
  • Mach-O
  • dyld
  • Virtual Memory
  • Page fault
  • Dirty Page & Clean Page
• main函数之前
  • dyld2
  • dyld3
• main函数之后
• 启动时间优化
  • 冷启动 VS 热启动
  • 分析方法
  • 优化实践

Runloop 是和线程紧密相关的一个基础组件，是很多线程有关功能的幕后功臣。尽管在平常使用中几乎不太会直接用到，理解 Runloop 有利于我们更加深入地理解 iOS 的多线程模型。

本文从如下几个方面理解RunLoop的相关知识点。

• RunLoop概念
• RunLoop实现
• RunLoop运行
• RunLoop应用

RunLoop概念

RunLoop介绍

RunLoop 是什么？RunLoop 还是比较顾名思义的一个东西，说白了就是一种循环，只不过它这种循环比较高级。一般的 while 循环会导致 CPU 进入忙等待状态，而 RunLoop 则是一种“闲”等待，这部分可以类比 Linux 下的 epoll。当没有事件时，RunLoop 会进入休眠状态，有事件发生时， RunLoop 会去找对应的 Handler 处理事件。RunLoop 可以让线程在需要做事的时候忙起来，不需要的话就让线程休眠。

本文主要以下几个方面详细介绍了iOS中所涉及的内存管理相关的机制

• 数据结构中的堆和栈
• 内存分配中的堆和栈
• 引用计数介绍
• MRC详解
• @autoreleasepool
• ARC详解
• 内存管理相关关键字的底层实现
• 内存泄漏及检测

之前的文章我们详细介绍了iOS中使用多线程的方式，但是一直没有细致的讲解如何在多线程的情况下保证线程的安全，今天我们就介绍下iOS中多线程中保证线程安全的方式之一锁机制

在具体说这些锁之前，先来说几个概念定义：(参考维基百科)

1. 临界区：指的是一块对公共资源进行访问的代码，并非一种机制或是算法。
2. 自旋锁：是用于多线程同步的一种锁，线程反复检查锁变量是否可用。由于线程在这一过程中保持执行，因此是一种忙等待。一旦获取了自旋锁，线程会一直保持该锁，直至显式释放自旋锁。 自旋锁避免了进程上下文的调度开销，因此对于线程只会阻塞很短时间的场合是有效的。
3. 互斥锁（Mutex）：是一种用于多线程编程中，防止两条线程同时对同一公共资源（比如全局变量）进行读写的机制。该目的通过将代码切片成一个一个的临界区而达成。
4. 读写锁（共享-互斥锁）：是计算机程序的并发控制的一种同步机制，也称“共享-互斥锁”、多读者-单写者锁) 用于解决多线程对公共资源读写问题。读操作可并发重入，写操作是互斥的。 读写锁通常用互斥锁、条件变量、信号量实现。
5. 信号量（semaphore）：是一种更高级的同步机制，互斥锁可以说是semaphore在仅取值0/1时的特例。信号量可以有更多的取值空间，用来实现更加复杂的同步，而不单单是线程间互斥。
6. 条件锁：就是条件变量，当进程的某些资源要求不满足时就进入休眠，也就是锁住了。当资源被分配到了，条件锁打开，进程继续运行。

本文主要介绍以下11种锁的使用方式，对原理性质介绍较少，针对每种锁的工作机制，大家可以自行科普。