追 MM 少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是 MM 爱吃的东西，虽然口味有所不同，但不管你带 MM 去麦当劳或肯德基，只管向服务员说「来四个鸡翅」就行了。麦当劳和肯德基就是生产鸡翅的 Factory 工厂模式：客户类和工厂类分开。

消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。

MM 最爱听的就是「我爱你」这句话了，见到不同地方的 MM，要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到 MM 我只要按对应的键，它就能够用相应的语言说出「我爱你」这句话了，国外的 MM 也可以轻松搞掂，这就是我的「我爱你」builder。

建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。

请 MM 去麦当劳吃汉堡，不同的 MM 有不同的口味，要每个都记住是一件烦人的事情，我一般采用 Factory Method 模式，带着 MM 到服务员那儿，说「要一个汉堡」，具体要什么样的汉堡呢，让 MM 直接跟服务员说就行了。

工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。

跟 MM 用 QQ 聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要 copy 出来放到 QQ 里面就行了，这就是我的情话 prototype 了。（100 块钱一份，你要不要）

原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。

俺有 6 个漂亮的老婆，她们的老公都是我，我就是我们家里的老公 Sigleton，她们只要说道「老公」，都是指的同一个人，那就是我 (刚才做了个梦啦，哪有这么好的事)

单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的 “单一实例” 的需求时才可使用。

在朋友聚会上碰到了一个美女 Sarah，从香港来的，可我不会说粤语，她不会说普通话，只好求助于我的朋友 kent 了，他作为我和 Sarah 之间的 Adapter，让我和 Sarah 可以相互交谈了 (也不知道他会不会耍我)

适配器（变压器）模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。

早上碰到 MM，要说早上好，晚上碰到 MM，要说晚上好；碰到 MM 穿了件新衣服，要说你的衣服好漂亮哦，碰到 MM 新做的发型，要说你的头发好漂亮哦。不要问我 “早上碰到 MM 新做了个发型怎么说” 这种问题，自己用 BRIDGE 组合一下不就行了

桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合 / 聚合关系而不是继承关系，从而使两者可以独立的变化。

Mary 今天过生日。“我过生日，你要送我一件礼物。”“嗯，好吧，去商店，你自己挑。”“这件 T 恤挺漂亮，买，这条裙子好看，买，这个包也不错，买。”“喂，买了三件了呀，我只答应送一件礼物的哦。”“什么呀，T 恤加裙子加包包，正好配成一套呀，小姐，麻烦你包起来。”“……”，MM 都会用 Composite 模式了，你会了没有？

合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。

Mary 过完轮到 Sarly 过生日，还是不要叫她自己挑了，不然这个月伙食费肯定玩完，拿出我去年在华山顶上照的照片，在背面写上 “最好的的礼物，就是爱你的 Fita”，再到街上礼品店买了个像框（卖礼品的 MM 也很漂亮哦），再找隔壁搞美术设计的 Mike 设计了一个漂亮的盒子装起来……，我们都是 Decorator，最终都在修饰我这个人呀，怎么样，看懂了吗？

装饰模式：装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给一个对象增加功能，这些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。

我有一个专业的 Nikon 相机，我就喜欢自己手动调光圈、快门，这样照出来的照片才专业，但 MM 可不懂这些，教了半天也不会。幸好相机有 Facade 设计模式，把相机调整到自动档，只要对准目标按快门就行了，一切由相机自动调整，这样 MM 也可以用这个相机给我拍张照片了。门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。

门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。

每天跟 MM 发短信，手指都累死了，最近买了个新手机，可以把一些常用的句子存在手机里，要用的时候，直接拿出来，在前面加上 MM 的名字就可以发送了，再不用一个字一个字敲了。共享的句子就是 Flyweight，MM 的名字就是提取出来的外部特征，根据上下文情况使用。享元模式：FLYWEIGHT 在拳击比赛中指最轻量级。

享元模式以共享的方式高效的支持大量的细粒度对象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存储在享元内部，不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状态不能影响内蕴状态，它们是相互独立的。

将可以共享的状态和不可以共享的状态从常规类中区分开来，将不可以共享的状态从类里剔除出去。客户端不可以直接创建被共享的对象，而应当使用一个工厂对象负责创建被共享的对象。享元模式大幅度的降低内存中对象的数量。

跟 MM 在网上聊天，一开头总是 “hi, 你好”,“你从哪儿来呀？”“你多大了？”“身高多少呀？” 这些话，真烦人，写个程序做为我的 Proxy 吧，凡是接收到这些话都设置好了自己的回答，接收到其他的话时再通知我回答，怎么样，酷吧。

代理模式：代理模式给某一个对象提供一个代理对象，并由代理对象控制对源对象的引用。代理就是一个人或一个机构代表另一个人或者一个机构采取行动。某些情况下，客户不想或者不能够直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的作用。

客户端分辨不出代理主题对象与真实主题对象。代理模式可以并不知道真正的被代理对象，而仅仅持有一个被代理对象的接口，这时候代理对象不能够创建被代理对象，被代理对象必须有系统的其他角色代为创建并传入。

晚上去上英语课，为了好开溜坐到了最后一排，哇，前面坐了好几个漂亮的 MM 哎，找张纸条，写上 “Hi, 可以做我的女朋友吗？如果不愿意请向前传”，纸条就一个接一个的传上去了，糟糕，传到第一排的 MM 把纸条传给老师了，听说是个老处女呀，快跑！

责任链模式：在责任链模式中，很多对象由每一个对象对其下家的引用而接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求，系统可以在不影响客户端的情况下动态的重新组织链和分配责任。处理者有两个选择：承担责任或者把责任推给下家。一个请求可以最终不被任何接收端对象所接受。

俺有一个 MM 家里管得特别严，没法见面，只好借助于她弟弟在我们俩之间传送信息，她对我有什么指示，就写一张纸条让她弟弟带给我。这不，她弟弟又传送过来一个 COMMAND，为了感谢他，我请他吃了碗杂酱面，哪知道他说：“我同时给我姐姐三个男朋友送 COMMAND，就数你最小气，才请我吃面。”

命令模式：命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。命令模式允许请求的一方和发送的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否执行，何时被执行以及是怎么被执行的。系统支持命令的撤消。

俺有一个《泡 MM 真经》，上面有各种泡 MM 的攻略，比如说去吃西餐的步骤、去看电影的方法等等，跟 MM 约会时，只要做一个 Interpreter，照着上面的脚本执行就可以了。

解释器模式：给定一个语言后，解释器模式可以定义出其文法的一种表示，并同时提供一个解释器。客户端可以使用这个解释器来解释这个语言中的句子。解释器模式将描述怎样在有了一个简单的文法后，使用模式设计解释这些语句。

在解释器模式里面提到的语言是指任何解释器对象能够解释的任何组合。在解释器模式中需要定义一个代表文法的命令类的等级结构，也就是一系列的组合规则。每一个命令对象都有一个解释方法，代表对命令对象的解释。命令对象的等级结构中的对象的任何排列组合都是一个语言。

我爱上了 Mary，不顾一切的向她求婚。Mary：“想要我跟你结婚，得答应我的条件” 我：“什么条件我都答应，你说吧” Mary：“我看上了那个一克拉的钻石” 我：“我买，我买，还有吗？” Mary：“我看上了湖边的那栋别墅” 我：“我买，我买，还有吗？” Mary：“我看上那辆法拉利跑车” 我脑袋嗡的一声，坐在椅子上，一咬牙：“我买，我买，还有吗？”

迭代子模式：迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。多个对象聚在一起形成的总体称之为聚集，聚集对象是能够包容一组对象的容器对象。迭代子模式将迭代逻辑封装到一个独立的子对象中，从而与聚集本身隔开。

迭代模式简化了聚集的界面。每一个聚集对象都可以有一个或一个以上的迭代子对象，每一个迭代子的迭代状态可以是彼此独立的。迭代算法可以独立于聚集角色变化。

四个 MM 打麻将，相互之间谁应该给谁多少钱算不清楚了，幸亏当时我在旁边，按照各自的筹码数算钱，赚了钱的从我这里拿，赔了钱的也付给我，一切就 OK 啦，俺得到了四个 MM 的电话。调停者模式：调停者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显作用。从而使他们可以松散偶合。

当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互作用转化为一对多的相互作用。调停者模式将对象的行为和协作抽象化，把对象在小尺度的行为上与其他对象的相互作用分开处理。

同时跟几个 MM 聊天时，一定要记清楚刚才跟 MM 说了些什么话，不然 MM 发现了会不高兴的哦，幸亏我有个备忘录，刚才与哪个 MM 说了什么话我都拷贝一份放到备忘录里面保存，这样可以随时察看以前的记录啦。

备忘录模式：备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下，将一个对象的状态捉住，并外部化，存储起来，从而可以在将来合适的时候把这个对象还原到存储起来的状态。

想知道咱们公司最新 MM 情报吗？加入公司的 MM 情报邮件组就行了，tom 负责搜集情报，他发现的新情报不用一个一个通知我们，直接发布给邮件组，我们作为订阅者（观察者）就可以及时收到情报啦。

观察者模式：观察者模式定义了一种一队多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使他们能够自动更新自己。

跟 MM 交往时，一定要注意她的状态哦，在不同的状态时她的行为会有不同，比如你约她今天晚上去看电影，对你没兴趣的 MM 就会说 “有事情啦”，对你不讨厌但还没喜欢上的 MM 就会说 “好啊，不过可以带上我同事么？”，已经喜欢上你的 MM 就会说 “几点钟？看完电影再去泡吧怎么样？”，当然你看电影过程中表现良好的话，也可以把 MM 的状态从不讨厌不喜欢变成喜欢哦。

状态模式：状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去象是改变了它的类一样。状态模式把所研究的对象的行为包装在不同的状态对象里，每一个状态对象都属于一个抽象状态类的一个子类。

状态模式的意图是让一个对象在其内部状态改变的时候，其行为也随之改变。状态模式需要对每一个系统可能取得的状态创立一个状态类的子类。当系统的状态变化时，系统便改变所选的子类。

跟不同类型的 MM 约会，要用不同的策略，有的请电影比较好，有的则去吃小吃效果不错，有的去海边浪漫最合适，单目的都是为了得到 MM 的芳心，我的追 MM 锦囊中有好多 Strategy 哦。策略模式：策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。

策略模式使得算法可以在不影响到客户端的情况下发生变化。策略模把行为和环境分开。环境类负责维持和查询行为类，各种算法在具体的策略类中提供。由于算法和环境独立开来，算法的增减，修改都不会影响到环境和客户端。

看过《如何说服女生上床》这部经典文章吗？女生从认识到上床的不变的步骤分为巧遇、打破僵局、展开追求、接吻、前戏、动手、爱抚、进去八大步骤 (Template method)，但每个步骤针对不同的情况，都有不一样的做法，这就要看你随机应变啦 (具体实现)；

模板方法模式：模板方法模式准备一个抽象类，将部分逻辑以具体方法以及具体构造子的形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。先制定一个顶级逻辑框架，而将逻辑的细节留给具体的子类去实现。

情人节到了，要给每个 MM 送一束鲜花和一张卡片，可是每个 MM 送的花都要针对她个人的特点，每张卡片也要根据个人的特点来挑，我一个人哪搞得清楚，还是找花店老板和礼品店老板做一下 Visitor，让花店老板根据 MM 的特点选一束花，让礼品店老板也根据每个人特点选一张卡，这样就轻松多了；

访问者模式：访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话，接受这个操作的数据结构可以保持不变。访问者模式适用于数据结构相对未定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由的演化。访问者模式使得增加新的操作变的很容易，就是增加一个新的访问者类。

访问者模式将有关的行为集中到一个访问者对象中，而不是分散到一个个的节点类中。当使用访问者模式时，要将尽可能多的对象浏览逻辑放在访问者类中，而不是放到它的子类中。访问者模式可以跨过几个类的等级结构访问属于不同的等级结构的成员类。

RedisInsight 是一个直观高效的 Redis GUI 管理工具，它可以对 Redis 的内存、连接数、命中率以及正常运行时间进行监控，并且可以在界面上使用 CLI 和连接的 Redis 进行交互（RedisInsight 内置对 Redis 模块支持）：

地址：https://docs.redis.com/latest/ri/

RedisInsight 提供的功能：

• 唯一支持 Redis Cluster 的 GUI 工具；
• 可以基于 Browser 的界面来进行搜索键、查看和编辑数据；
• 支持基于 SSL/TLS 的连接，同时还可以在界面上进行内存分析；

1）下载 RedisInsight 软件包：

地址：https://redis.com/redis-enterprise/redis-insight/#insight-form

[root@Redis ~]# ls
anaconda-ks.cfg  redisinsight-linux64-1.11.0
[root@Redis ~]# mkdir /usr/local/redisinsight
[root@Redis ~]# mv redisinsight-linux64-1.11.0 /usr/local/redisinsight/redisinsight-1.11.0
[root@Redis ~]# chmod +x /usr/local/redisinsight/redisinsight-1.11.0

2）配置 RedisInsight 的环境变量

[root@Redis ~]# echo "export REDISINSIGHT_HOST=192.168.1.1" >> ~/.bash_profile
[root@Redis ~]# echo "export REDISINSIGHT_HOST_DIR=/usr/local/redisinsight/.redisinsight" >> ~/.bash_profile
[root@Redis ~]# source ~/.bash_profile

注解：

• REDISINSIGHT_PORT：配置 RedisInsight 的监听端口（default：8001）
• REDISINSIGHT_HOST：配置 RedisInsight 的 IP 地址（default：0.0.0.0）
• LOG_DIR：配置 RedisInsight 的日志存放路径（default：REDISINSIGHT_HOST_DIR）
• REDISINSIGHT_HOST_DIR：配置 RedisInsight 的数据存放路径（default：~/.redisinsight）

3）启动 RedisInsight 服务

[root@Redis ~]# nohup /usr/local/redisinsight/redisinsight-linux64-1.4.0 &  // 后台运行
[root@Redis ~]# ps aux | grep redis            // 查看进程是否存在

1）创建 RedisInsight 的 yaml 文件：

[root@Redis ~]# vim redisinsight.yaml
apiVersion: v1
kind: Service
metadata:
  name: redisinsight-service
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 8001
    nodePort: 31888
  selector:
    app: redisinsight
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redisinsight
  labels:
    app: redisinsight
spec:
  replicas: 1
  selector:
    matachLabels:
      app: redisinsight
  template:
    metadata:
      labels:
        app: redisinsight
    spec:
      containers:
      - name: redisinsight
        image: redislabs/redisinsight:1.7.0
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - name: db
          mountPath: /db
        ports:
        - containerPort: 8001
          protocol: TCP
      volumes:
      - name: db
        emptyDir: {}

2）启动 RedisInsight

[root@Redis ~]# kubectl apply -f redisinsight.yaml

安装 Redis（已安装可直接跳过）

[root@Redis ~]# wget https://download.redis.io/releases/redis-6.2.6.tar.gz
[root@Redis ~]# tar zxf redis-6.2.6.tar.gz
[root@Redis ~]# cd redis-6.2.6
[root@Redis redis-6.2.6]# make PREFIX=/usr/local/redis install
[root@Redis redis-6.2.6]# sed -i '/^bind 127.0.0.1/s/127.0.0.1/192.168.1.1/g' redis.conf  # 修改监听 IP
[root@Redis redis-6.2.6]# sed -i '/protected-mode/s/yes/no/g' redis.conf      # 关闭保护模式
[root@Redis redis-6.2.6]# sed -i '/daemonize/s/no/yes/g' redis.conf        # 开启后台运行
[root@Redis redis-6.2.6]# sed -i '/requirepass/s/foobared/123123/g' redis.conf     # 配置密码
[root@Redis redis-6.2.6]# sed -i '/requirepass 123123/s/^#//g' redis.conf      # 将密码前的 # 删除
[root@Redis redis-6.2.6]# cp redis.conf /usr/local/redis/
[root@Redis redis-6.2.6]# /usr/local/redis/bin/redis-server /usr/local/redis/redis.conf   # 启动 Redis

1）通过配置的 IP 和端口，来访问 RedisInsight 的管理界面：

2）在这里可以看到 Redis 的各种信息：

3）同时 RedisInsight 还可以在界面上进行操作：

4）还可以在界面上对 Redis 使用的内存进行分析：

• 引言
• API介绍
• 实战使用

引言

在文章的开头，先说下NPE问题，NPE问题就是，我们在开发中经常碰到的NullPointerException.假设我们有两个类，他们的UML类图如下图所示

在这种情况下，有如下代码

user.getAddress().getProvince();

这种写法，在user为null时，是有可能报NullPointerException异常的。为了解决这个问题，于是采用下面的写法

if(user!=null){
    Address address = user.getAddress();
    if(address!=null){
        String province = address.getProvince();
    }
}

这种写法是比较丑陋的，为了避免上述丑陋的写法，让丑陋的设计变得优雅。JAVA8提供了Optional类来优化这种写法，接下来的正文部分进行详细说明

先介绍一下API，与其他文章不同的是，本文采取类比的方式来讲，同时结合源码。而不像其他文章一样，一个个API罗列出来，让人找不到重点。

这四个函数之间具有相关性，因此放在一组进行记忆。

先说明一下，Optional(T value)，即构造函数，它是private权限的，不能由外部调用的。其余三个函数是public权限，供我们所调用。那么，Optional的本质，就是内部储存了一个真实的值，在构造的时候，就直接判断其值是否为空。好吧，这么说还是比较抽象。直接上Optional(T value)构造函数的源码，如下图所示

那么，of(T value)的源码如下

public static  Optional of(T value) {
    return new Optional(value);
}

也就是说of(T value)函数内部调用了构造函数。根据构造函数的源码我们可以得出两个结论:

• 通过of(T value)函数所构造出的Optional对象，当Value值为空时，依然会报NullPointerException。

• 通过of(T value)函数所构造出的Optional对象，当Value值不为空时，能正常构造Optional对象。

除此之外呢，Optional类内部还维护一个value为null的对象，大概就是长下面这样的

public final class OptionalT> {
    //省略....
    private static final Optional> EMPTY = new Optional();
    private Optional() {
        this.value = null;
    }
    //省略...
    public static Optional empty() {
        @SuppressWarnings("unchecked")
        Optional t = (Optional) EMPTY;
        return t;
    }
}

那么，empty（）的作用就是返回EMPTY对象。

好了铺垫了这么多，可以说ofNullable(T value)的作用了，上源码

 public static  Optional ofNullable(T value) {
    return value == null ? empty() : of(value);
}

好吧，大家应该都看得懂什么意思了。相比较of(T value)的区别就是，当value值为null时，of(T value)会报NullPointerException异常；ofNullable(T value)不会throw Exception，ofNullable(T value)直接返回一个EMPTY对象。

那是不是意味着，我们在项目中只用ofNullable函数而不用of函数呢?

不是的，一个东西存在那么自然有存在的价值。当我们在运行过程中，不想隐藏NullPointerException。而是要立即报告，这种情况下就用Of函数。但是不得不承认，这样的场景真的很少。博主也仅在写junit测试用例中用到过此函数。

这三个函数放一组进行记忆，都是在构造函数传入的value值为null时，进行调用的。orElse和orElseGet的用法如下所示，相当于value值为null时，给予一个默认值:

@Test
public void test() {
    User user = null;
    user = Optional.ofNullable(user).orElse(createUser());
    user = Optional.ofNullable(user).orElseGet(() -> createUser());

}
public User createUser(){
    User user = new User();
    user.setName("zhangsan");
    return user;
}

这两个函数的区别：当user值不为null时，orElse函数依然会执行createUser()方法，而orElseGet函数并不会执行createUser()方法，大家可自行测试。

至于orElseThrow，就是value值为null时,直接抛一个异常出去，用法如下所示

User user = null;
Optional.ofNullable(user).orElseThrow(()->new Exception("用户不存在"));

这两个函数放在一组记忆，这两个函数做的是转换值的操作。

直接上源码

 public final class OptionalT> {
    //省略....
     public Optional map(Function super T, ? extends U> mapper) {
        Objects.requireNonNull(mapper);
        if (!isPresent())
            return empty();
        else {
            return Optional.ofNullable(mapper.apply(value));
        }
    }
    //省略...
     public Optional flatMap(Function super T, Optional> mapper) {
        Objects.requireNonNull(mapper);
        if (!isPresent())
            return empty();
        else {
            return Objects.requireNonNull(mapper.apply(value));
        }
    }
}

这两个函数，在函数体上没什么区别。唯一区别的就是入参，map函数所接受的入参类型为Function super T, ? extends U>，而flapMap的入参类型为Function super T, Optional>。

在具体用法上，对于map而言：

如果User结构是下面这样的

public class User {
    private String name;
    public String getName() {
        return name;
    }
}

这时候取name的写法如下所示

String city = Optional.ofNullable(user).map(u-> u.getName()).get();

对于flatMap而言:

如果User结构是下面这样的

public class User {
    private String name;
    public Optional getName() {
        return Optional.ofNullable(name);
    }
}

这时候取name的写法如下所示

String city = Optional.ofNullable(user).flatMap(u-> u.getName()).get();

这两个函数放在一起记忆，isPresent即判断value值是否为空，而ifPresent就是在value值不为空时，做一些操作。这两个函数的源码如下

public final class OptionalT> {
    //省略....
    public boolean isPresent() {
        return value != null;
    }
    //省略...
    public void ifPresent(Consumer super T> consumer) {
        if (value != null)
            consumer.accept(value);
    }
}

需要额外说明的是，大家千万不要把

if (user != null){
   // TODO: do something
}

给写成

User user = Optional.ofNullable(user);
if (Optional.isPresent()){
   // TODO: do something
}

因为这样写，代码结构依然丑陋。博主会在后面给出正确写法

至于ifPresent(Consumer super T> consumer)，用法也很简单，如下所示

Optional.ofNullable(user).ifPresent(u->{
    // TODO: do something
});

不多说，直接上源码

public final class OptionalT> {
    //省略....
   Objects.requireNonNull(predicate);
        if (!isPresent())
            return this;
        else
            return predicate.test(value) ? this : empty();
}

filter 方法接受一个 Predicate 来对 Optional 中包含的值进行过滤，如果包含的值满足条件，那么还是返回这个 Optional；否则返回 Optional.empty。

用法如下

Optional user1 = Optional.ofNullable(user).filter(u -> u.getName().length()6);

如上所示，如果user的name的长度是小于6的，则返回。如果是大于6的，则返回一个EMPTY对象。

在函数方法中

以前写法

public String getCity(User user)  throws Exception{
        if(user!=null){
            if(user.getAddress()!=null){
                Address address = user.getAddress();
                if(address.getCity()!=null){
                    return address.getCity();
                }
            }
        }
        throw new Excpetion("取值错误");
    }

JAVA8写法

public String getCity(User user) throws Exception{
    return Optional.ofNullable(user)
                   .map(u-> u.getAddress())
                   .map(a->a.getCity())
                   .orElseThrow(()->new Exception("取指错误"));
}

比如，在主程序中

以前写法

if(user!=null){
    dosomething(user);
}

JAVA8写法

 Optional.ofNullable(user)
    .ifPresent(u->{
        dosomething(u);
});

以前写法

public User getUser(User user) throws Exception{
    if(user!=null){
        String name = user.getName();
        if("zhangsan".equals(name)){
            return user;
        }
    }else{
        user = new User();
        user.setName("zhangsan");
        return user;
    }
}

java8写法

public User getUser(User user) {
    return Optional.ofNullable(user)
                   .filter(u->"zhangsan".equals(u.getName()))
                   .orElseGet(()-> {
                        User user1 = new User();
                        user1.setName("zhangsan");
                        return user1;
                   });
}

其他的例子，不一一列举了。不过采用这种链式编程，虽然代码优雅了。但是，逻辑性没那么明显，可读性有所降低，大家项目中看情况酌情使用。

• 1 众说纷纭：我们的架构设计究竟出了什么问题？
• 2 看看亚马逊 CTO 和前云架构战略副总裁怎么说

编译 | 明知山、Tina

Ruby on Rails 之父：“即使是亚马逊也无法理解无服务器或微服务。”

来自亚马逊 Prime Video 团队的一个案例研究在开发者社区中掀起了轩然大波。

在该案例中，Prime Video 团队将一个监控系统从微服务架构迁移到单体架构，并避免使用昂贵的服务（如 AWS Step Functions 和 Lambda 无服务器函数），并对此举所带来的降本效果进行了评估。

他们的需求是使用一个监控工具来识别“用户查看的视频流”的质量问题，因为有“成千上万个并发流”，所以这个工具必须是高度可伸缩的。团队最初构建了一个由 AWS Step Functions 编排而成的分布式组件解决方案，一个基于状态机和任务的无服务器编排服务。结果发现，Step Functions 居然是瓶颈所在。

案例文章中写道：“对于视频流的每一秒，我们的服务都需要执行多次状态转换，所以很快就达到了账户限制。除此之外，AWS Step Functions 是按照状态转换向用户收费的。”还有另外一个“成本问题”，即存在大量对 S3 的一级调用（用于临时存储捕获的视频帧）。

Prime Video 监控应用程序的初始架构，可见成本很高，伸缩性也很差

案例文章中写道：“我们意识到分布式架构在这个特定的场景中并没有为我们带来太大的好处，所以我们将所有组件都合并到一个进程中”，从而消除了对 S3 的依赖。“我们还实现了在单个实例中控制组件的编排。”现在，这个解决方案运行在 EC2（Elastic Compute Cloud）和 ECS（Elastic Container Service）上，其中有“一个轻量级的编排层来分发用户请求”。

案例文章总结道：“微服务和无服务器组件可以被用在大规模的场景中，但是否一定要舍弃单体而使用它们则需要根据具体情况具体分析。将服务迁移成单体让我们的基础设施成本降低了 90% 以上，还提升了我们的伸缩能力。 ”文中还提到了他们通过 EC2 节省计划来降低成本，这说明即使是内部 AWS 用户也会按照与外部用户类似的模式收取费用。

1 众说纷纭：我们的架构设计究竟出了什么问题？

这篇文章最初是在三月份发布的，但是直到这个月才引起整个工程界和技术界的关注。

Hacker News 上的一条评论说：“这篇文章的存在让我感到很惊讶，甚至都有点看傻眼了”。

在我们看来，AWS 总是习惯于将微服务和无服务器架构宣扬成“现代化”应用程序的最佳实践。例如，“AWS Well-Architected”文档的“Reliability”一项下面给出了一些建议：

“使用面向服务架构（SOA）或微服务架构构建高度可伸缩和可靠的工作负载。面向服务架构是一种通过服务接口让软件组件变得可重用的实践。微服务架构则进一步让组件变得更小、更简单。”

在关于.NET 应用程序现代化的“AWS Prescriptive Guidance”文档中，亚马逊列出了微服务的好处，包括更快的创新、高可用性和可靠性、更高的敏捷性和按需可伸缩性、现代 CI/CD（持续集成和部署）管道，以及强大的模块边界，尽管它也将“运维复杂性”列为缺点。

然而，这篇案例文章似乎证实了开发者的一些猜疑。其中的一个猜疑是，AWS 推荐的解决方案可能不是最具成本效益的，因为它们总是涉及到使用多种昂贵的服务。另一个猜疑是微服务相对于单体应用的优点似乎被夸大了。

Ruby on Rails 作者 David Heinemeier Hansson 一直在倡导减少对云服务的使用，他在评论亚马逊的这个案例研究时表示，它“对一度席卷科技行业的理论上的微服务热潮来了一次大总结 。现在，这些理论的实际结果终于出来了。很明显，在实践中，微服务可能会给系统带来不必要的复杂性。而无服务器只会让情况变得更糟。一个团队，一个应用程序，却用网络调用和服务分区取代方法调用和模块分离，这在任何一种情况下几乎都是很疯狂的。”

“即使是亚马逊也无法理解无服务器或微服务。”

2020 年，“Building Microservices”和“Monolith to Microservices”等书的作者 Sam Newman 在一次开发者大会上表示，“微服务不应该是默认的选择 ”，并向软件架构师提出了一些在采用微服务架构之前需要考虑的事项：“你做过价值链分析吗？你了解过瓶颈出现在哪里吗？你尝试过模块化吗？微服务应该是最后才去考虑的。”

现在，Newman 在推特上对这篇案例文章做了评论：“这篇文章实际上更多的是关于函数与长时间运行的虚拟机的定价模型。这仍然是完全合乎逻辑的架构驱动，但从这个案例中学到的东西，其适用性范围可能相对要狭窄一些。”他接着写道：“人们之所以不公开谈论撤离微服务，是因为这可能会让一些人认为‘他们做错了’ 。视情况变化而改变你的想法才是对的做法。”

关于这篇文章的讨论随处可见，它激起了大量的思考，在 Hacker News、Twitter、Reddit 等平台上涌现了非常多的有意思的评论和分析。

就像一位网友在 Hacker News 上评论的那样：“这是一个很好的教训，一个很好的故事，而且很重要的是它来自亚马逊内部团队。”

对于该案例的初始架构设计存在的问题，一位 DataDog 高级软件工程师 Lambros Petrou 在推特上发表了分析：“Prime Video 案例文章中的设计是有问题的。滥用服务并不能解决架构问题，它只会把问题暴露出来”。前首席技术官 Steve Chambers 在某种程度上也同意这一观点，他说：“基本上，他们（现在）使用的是相同的架构，只是将组件塞到了容器中，这样他们就不会在不同的云服务之间通过网络进行昂贵的调用和数据传输……这很明显是一种优化！”

一名工程师在 Reddit 上针对这个案例争论道：“微服务是有额外开销的。本来简单的进程间通信，或者系统两个部件之间的内存调用，变成了 HTTPS、OAuth、JSON 编码 / 解码，而且每次都需要发生这些简短的对话。当你的系统被分解成 50 万个部件，每一次通信都需要做这些事情，并且你要为每一个事务付费时，成本和复杂性就会增加。拆解单体需要一次性替换整个应用程序，这意味着开发人员需要做一些测试。但 DevOps 意味着不会有更多的测试，所以在生产环境中会发生故障，我们唯一能做的是让功能块变小，这样才可能快速找到和修复问题。”

但总的来说，这篇案例文章对于 AWS 来说未必是坏消息。一方面，这似乎与这家云计算巨头所宣扬的最佳实践背道而驰，但另一方面，这也是一个令人耳目一新的关于如何通过简单的架构来降低成本的实践。与许多促销案例研究不同，这个案例看起来对 AWS 客户真的很有用。

2 看看亚马逊 CTO 和前云架构战略副总裁怎么说

这件事情被大家传得沸沸扬扬的，甚至还惊动了亚马逊 CTO Werner Vogels 博士。

他对此表示，构建可演进的软件系统是一种策略，我们必须以开放的心态重新审视自己的架构。

“软件架构不像桥梁和房屋的架构。桥梁建成后就很难改变，但软件不一样。软件一旦运行起来，我们就可以更深入地了解我们的工作负载，然后再选择一个可演进的架构，在不影响客户体验的情况下进行更改。我的经验法则是，随着每个数量级的增长，你都应该重新审视你的架构，并确定它是否仍能支持下一个数量级的增长。”

“Prime Video 就是个很好的例子。（架构设计）没有放之四海而皆准的方法。我们总是敦促我们的工程师找到最佳解决方案，并且我们没有强制要求特定的架构风格。”“我想重申，没有一种架构模式可以满足所有的情况……单体没有消亡（恰恰相反），可演进的架构也在不断变化的技术格局中扮演着越来越重要的角色。”

在 Werner Vogels 博士发表看法之后，去年已宣布退休的前亚马逊云科技可持续发展架构副总裁、前云架构战略副总裁 Adrian Cockcroft 也忍不住出来点评了一下。

“关于 Prime Video 的案例，虽然互联网上涌现了堆积如山的意见和观点，但大多没有说到点子上。”

Prime Video 团队只是遵循了一条“Serverless First（无服务器优先）”的原则：首先尝试使用 Step Functions 和 Lambda 进行快速构建。通过无服务器方法，在几天或几周内构建一个原型，这是重点。然后在需要应对高流量时，再进行重构。“Serverless First”和“Serverless Only”是有区别的，“我不提倡 Serverless Only”。

他认为这个案例之所以会引起这么大的反应，关键是“在微服务被过度营销的情况下，大家以为 Prime Video 团队返回到了单体架构”。

“我确实认为微服务被过度宣传了，把微服务作为解决所有问题的答案。而且这可能是因为厂商想通过简单的营销信息来销售 Kubernetes，即需要通过使用 Kubernetes 来实现云原生的微服务。大家对这种信息传递方式表示了强烈的反对。Kubernetes 的复杂性是有代价的，除非你的团队和规模非常大，否则你不需要它。（建议阅读 Sam Newman 的《构建微服务：设计细粒度系统》一书。）”

总之，Prime Video 团队最初的设计还是很棒的，帮助他们快速进入市场并带来收益。而现在，他们在退后一步进行下一阶段的分析。“该团队遵循了我认为的最佳实践”，“我认为 Prime 团队发布的这篇文章非常富有洞察力……”

参考链接：

https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90

https://world.hey.com/dhh/even-amazon-can-t-make-sense-of-serverless-or-microservices-59625580

Reduce costs by 90% by moving from microservices to monolith: Amazon internal case study raises eyebrows

https://thestack.technology/amazon-prime-video-microservices-monolith/

https://news.ycombinator.com/item?id=35811741

https://twitter.com/samnewman/status/1654432661337788416

https://www.allthingsdistributed.com/2023/05/monoliths-are-not-dinosaurs.html

https://adrianco.medium.com/so-many-bad-takes-what-is-there-to-learn-from-the-prime-video-microservices-to-monolith-story-4bd0970423d4

• Java 17 用户采用率在一年内增长了 430%
• Java 14 是最受欢迎的非 LTS 版本
• Amazon 是现在最受欢迎的 JDK 供应商

New Relic 最新发布了一份 “2023 年 Java 生态系统状况报告”，旨在提供有关当今 Java 生态系统状态的背景和见解。该报告基于从数百万个提供性能数据的应用程序中收集的数据，对生产中使用最多的版本、最受欢迎的 JDK 供应商、容器的兴起等多方面进行了调研分析。

Java 17 用户采用率在一年内增长了 430%

Java 每两到三年推出一个长期支持 (LTS) 版本。其中，目前最受欢迎的一个版本是 2018 年 9 月发布的 Java 11；有超过 56% 的应用程序在生产中使用它，高于 2022 年的 48% 和 2020 年的 11% 占比。2014 年发布的 Java 8 紧随其后，近 33% 的应用程序在生产中使用该版本，低于 2022 年的 46%。

报告称，虽然 Java 11 已经连续两年占据榜首，但 Java 17 (2021 年 9 月发布) 的采用率增长远远超过了 Java 11 推出时的情况。现共有超过 9% 的应用程序在生产中使用 Java 17 (2022 年还不到 1%)，这意味着其在一年内实现了 430% 的增长率。而 Java 11 花了多年时间才达到接近这个水平的增长。

对 Java 7 (2011 年 7 月发布的 LTS 版本) 的支持已于 2022 年结束，现只有 0.28% 的应用程序仍在生产中使用该版本。大多数使用 Java 7 的应用程序都是尚未升级的遗留应用程序。

Java 14 是最受欢迎的非 LTS 版本

与 LTS 版本相比，仅支持六个月的非 LTS Java 版本的使用率仍然极低；只有 1.6% 的应用程序使用非 LTS Java 版本，低于 2022 年的 2.7%。其中，于 2020 年 1 月发布的 Java 14 仍然是最受欢迎的非 LTS 版本；使用率为 0.57%，低于 2022 年的 0.95%。Java 15 紧随其后为 0.44%，低于 2022 年的 0.70%。

报告认为，导致非 LTS 版本使用率下降的一些可能因素包括：

• 缺乏支持
• 特性的感知吸引力
• 距离下一个 LTS 版本的时间长度

Amazon 是现在最受欢迎的 JDK 供应商

2020 年，甲骨文是最受欢迎的 JDK 供应商，占据了大约 75% 的市场份额。2022 年，甲骨文虽然保住了第一的市占位置，但其份额已经缩水了近一半，跌至 34%，2023 年还继续下滑到了 28%。New Relic 认为，导致这一现象的主要原因是甲骨文对 Java 11 的限制性许可。此后，该公司对 Java 17 恢复了更加开放的立场。

与此同时，Amazon Corretto 使用率大幅增加成为最常用的 Java 开发工具包，市场份额达到 31%。使得该公司成为最受欢迎的 JDK 供应商，其 2020 和 2022 年的市占分别为 2.18% 和 22%。

报告中的一些其他内容还包括：

• 容器化应用程序已成为主流 —— 向 New Relic 报告的 Java 应用中有 70% 是从容器中进行的。
• Garbage-First (G1) 垃圾收集器仍然是使用 Java 11 或更高版本的用户的最爱，有 65% 的使用率。其他在 Java 8 之后出现的实验性垃圾收集器（ZGC 和 Shenandoah）在生产系统中的使用仍然很少。两者都有生产就绪版本，但在一般处理中仍然可以忽略不计。

更多详情可查看完整报告：https://newrelic.com/resources/report/2023-state-of-the-java-ecosystem

来源：blog.csdn.net/q1472750149/article/

details/121886327