Zhu.Yang

实参和形参

1
2
3
4
5

public int sum(int x,int y) {
    return x+y;
}

sum(2,3);

上面的代码中 sum () 方法中的 x,y 就是形参，而调用方法 sum (2,3) 中的 2 与 3 就是实参。形参是在方法定义阶段，而实参实在方法调用阶段。

之前看了许多介绍 Java8 Stream 的文章，但是初次接触真的是难以理解 (我悟性比较低), 没办法只能” 死记硬背”, 但是昨天我打王者荣耀 (那一局我赢了，牛魔全场 MVP) 的时候，突然迸发了灵感，感觉之前没有理解透彻的一下子就理解透彻了。所以决定用简单的方式来回忆下我认为的 java8 Stream.

lambda 表达式

语法

lambda 表达式是 Stream API 的基石，所以想要学会 Stream API 的使用，必须先要理解 lambda 表达式，这里对 lambda 做一个简单回顾。

我们常常会看到这样的代码

1
2
3
4
5
6

Arrays.sort(new Integer[]{1, 8, 7, 4}, new Comparator<Integer>() {
   @Override
   public int compare(Integer first, Integer second) {
       return first.compareTo(second);
   }
});

talk is easy,show me the code, 先来看一段创建 producer 的代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

public class KafkaProducerDemo {

  public static void main(String[] args) {

    KafkaProducer<String,String> producer = createProducer();

    //指定topic,key,value
    ProducerRecord<String,String> record = new ProducerRecord<>("test1","newkey1","newvalue1");

    //异步发送
    producer.send(record);
    producer.close();

    System.out.println("发送完成");

  }

  public static KafkaProducer<String,String> createProducer() {
    Properties props = new Properties();

    //bootstrap.servers 必须设置
    props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "192.168.239.131:9092");

    // key.serializer   必须设置
    props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());

    // value.serializer  必须设置
    props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());

    //client.id
    props.put(ProducerConfig.CLIENT_ID_CONFIG, "client-0");

    //retries
    props.put(ProducerConfig.RETRIES_CONFIG, 3);

    //acks
    props.put(ProducerConfig.ACKS_CONFIG, "all");

    //max.in.flight.requests.per.connection
    props.put(ProducerConfig.MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION, 1);
    
    //linger.ms
    props.put(ProducerConfig.LINGER_MS_CONFIG, 100);

    //batch.size
    props.put(ProducerConfig.BATCH_SIZE_CONFIG, 10240);

    //buffer.memory
    props.put(ProducerConfig.BUFFER_MEMORY_CONFIG, 10240);

    return new KafkaProducer<>(props);
  }
}

大家好，我是 kafka, 可能很多人都听说过我，知道我是 2011 年出生在 LinkedIn 的，从那会儿到现在我的功能越发强大了。作为一个优秀而又完整的平台，你可以在我上面冗余地存储巨大的数据量，我有一个具有高吞吐量 (数百万 / 秒) 的消息总线，你可以在这上面对经过我的数据进行实时流处理。
如果你认为我就只有上面的这些特点的话，那么你真的是太肤浅了。

上面虽然说的很好，但是并未触及到我的核心，这里我给你几个关键字：分布式，水平可扩展，容错，提交日志。

上面这些抽象的词语，我会一一解释它们的含义，并告诉你们我是如何工作的。

内心独白：本来我是想要以第一人称来写这篇文章的，但是我发现我只能写出上面的了，再多的我就憋不出来了，于是我决定不要为难自己，还是用用第三人称写吧 (写作的功底仍然需要锻炼)

前面的文章讲的命令都是操作本地仓库的，我相信可以应付大部分的开发状况，提交代码到本地仓库已经不是问题了，那么这次我们就来看看如何和远程仓库进行对接。

git clone — 克隆远端代码到本地

当我们进行开发的时候，开发流程是这样的：首先将远程仓库 (中央仓库) 的代码 clone 到本地，在本地进行开发，开发完成之后将代码提交到远程仓库。

远程仓库并不复杂，实际上它们只是你的仓库在另外一台计算机上的拷贝，我们可以通过网络和这台计算机通信–也就是增加或是获取提交记录。我们先通过命令将远端仓库 clone 到本地

1

git clone https://github.com/generalthink/git_learn.git

执行命令之后 git 仓库就从远端 clone 到本地了，此时本地和远端的代码一致。执行了这个命令之后我们本地有什么变化呢？
先查看我们现在存在哪些分支

1
2
3
4

$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

上篇文章讲了 merge 和 rebase, 我们已经可以在 commit object 构成的图 (当然我更愿意把它看成一棵树) 上面进行分支的合并了，在图上我们可以新增节点 (git commit), 合并节点 (merge 或者 rebase), 这篇我们就来讲解下移动和删除节点。

在讲移动和删除之前，我们先来认识下 HEAD 的分离。

分离的 HEAD

我们都知道，HEAD 是指向当前分支的，而分离的 HEAD 就是让其指向了某个具体的提交记录而不是分支名。

现在我本地的提交记录是这样的

git log

当我们执行 git checkout 062704b1c3a814dfd95695aba3684c22e3f3fa85 之后 HEAD 就处于分离状态。

分离 HEAD

分离 HEAD

经过前面理论的学习，相信对 git 的模型已经有了一个比较深入的认识，在讲解常用开发命令之前，先看下 git 整体操作流程

git 流程

我们按照一个正常的开发流程来学习，我们现在要开始开发了，首先我们需要把远程仓库同步到本地

1

git clone https://github.com/generalthink/git_learn.git

运行完上面的命令，在我们的当前工作目录就会有一个 git_learn 的文件夹，其中存在.git 目录 (git 维护仓库的基本) 以及和远程仓库一样的文件，现在我们的代码环境就和远程仓库一致了，我们就可以开始我们的开发流程了。

暂存区

从 git 的角度来看，文件的修改涉及到以下三个区域：工作目录，stage 区 (暂存区) 以及本地仓库.

git 区域

当我们对我们的项目做了一些修改 (新增文件，删除文件，修改文件等), 我们处理的就是我们的工作目录。这个目录是存在于我们电脑的文件系统上的。所有的修改都会保留在工作目录直到我们把它们加入到暂存区 (通过 git add 命令).

在开发软件的时候，可能很多人会同时为同一个软件开发功能或者修复 bug, 但是如果都在主分支来进行开发，引起冲突的概率将会大大增加，而且也不利于维护，如果你同时修改多个 bug 该怎么办？所幸，git 的分支功能很好的帮助我们解决了这个问题，它可以帮助我们同时进行多个功能的开发和版本管理.
请在阅读这篇文章之前，务必先阅读深入浅出 git—— 数据模型 , 这样才能更好的帮助你理解 git 中的分支。想知道为什么 git 中新建一个分支那么快，代价那么小吗？接下来我们就来揭开分支神秘的面纱.

自 2005 年诞生以来，git 已经在开源世界中大受欢迎，我们中的许多人也在我们的工作岗位上使用它。 它是一个很棒的 VCS 工具，具有很多优点，但易于学习并不是其中之一。 对于 git 如果只会死记硬背命令那么要不了多久你就会忘记，然后一而再而三的背诵，无疑让人很受打击，在我看来，熟悉使用 git 甚至开始喜欢它的唯一方法是了解它如何在内部工作。

git 命令只是对数据存储的抽象，如果不了解 git 的工作原理，无论我们在笔记中记忆或存储了多少 git 命令或技巧我们仍然会对 git 的使用感到困惑。而 git 则是通过抽象的命令来暴露它的数据结构的使用方法.

所以这边文章我们更多的要关注 git 的内部关系 - 数据模型，当然这篇文章不会涉及到 git 的源码.