知一杂谈

我思故我在

发表于 分类于

领域驱动设计中定义了超多的概念，如果不多找几篇资料综合的去看，正确的理解比较困难，下面搜集整理了大部分的领域驱动中的概念，并加以理解描述。

战略设计与战术设计

战略设计主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。它是从高层事业来绅士我们的软件系统。从战略设计角度来看，一套基础的电商业务应该包含如下领域，支付域、交易域、商品域、库存域、履约域。不同领域之间通过界限上下文来划分边界。

战术设计则从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。它主要关注的是技术层面的实施，也是对我们程序员最实在的地方。战术设计的具体落地案例在后面的内容中会讲解。

领域 & 子领域

DDD 的领域就是这个边界内要解决的业务问题域。既然领域是用来限定业务边界和范围的，那么就会有大小之分，领域越大，业务范围就越大，反之则相反。领域可以进一步划分为子领域。我们把划分出来的多个子领域称为子域，每个子域对应一个更小的问题域或更小的业务范围。

核心域 & 通用域 & 支撑域

在领域不断划分的过程中，领域会细分为不同的子域，子域可以根据自身重要性和功能属性划分为三类子域，它们分别是：核心域、通用域和支撑域。决定产品和公司核心竞争力的子域是核心域，它是业务成功的主要因素和公司的核心竞争力。没有太多个性化的诉求，同时被多个子域使用的通用功能子域是通用域。还有一种功能子域是必需的，但既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，它就是支撑域。

基于以上概念定义，对订单域进行如下的拆分，其中交易子域和算价子域是最关键的核心子域，限购子域、交付子域、报表子域、会员订阅子域是支撑子域，消息子域为沟通各个子域的桥梁分类为通用子域。注意这里的曲线只是用来区分不同子域类型，不是界限上下文。

事件风暴

事件风暴是一项团队活动，领域专家与项目团队通过头脑风暴的形式，罗列出领域中所有的领域事件，整合之后形成最终的领域事件集合，然后对每一个事件，标注出导致该事件的命令，再为每一个事件标注出命令发起方的角色。命令可以是用户发起，也可以是第三方系统调用或者定时器触发等，最后对事件进行分类，整理出实体、聚合、聚合根以及限界上下文。而事件风暴正是 DDD 战略设计中经常使用的一种方法，它可以快速分析和分解复杂的业务领域，完成领域建模。

通用语言 & 界限上下文

在 DDD 领域建模和系统建设过程中，有很多的参与者，包括领域专家、产品经理、项目经理、架构师、开发经理和测试经理等。对同样的领域知识，不同的参与角色可能会有不同的理解，那大家交流起来就会有障碍，怎么办呢？因此，在 DDD 中就出现了“通用语言”和“限界上下文”这两个重要的概念。这两者相辅相成，通用语言定义上下文含义，限界上下文则定义领域边界，以确保每个上下文含义在它特定的边界内都具有唯一的含义，领域模型则存在于这个边界之内。

通用语言

团队交流达成共识的能够明确简单清晰的描述业务规则和业务含义的语言就是通用语言。解决各岗位的沟通障碍问题，促进不同岗位的和合作，确保业务需求的正确表达。通用语言贯穿于整个设计过程，基于通用语言可以开发出可读性更好的代码，能准确的把业务需求转化为代码。

界限上下文

用来封装通用语言和领域对象，提供上下文环境，保证在领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。这个边界定义了模型的适用范围，使团队所有成员能够明确地知道什么应该在模型中实现，什么不应该在模型中实现。

栗子说明

在商品域，商品实体则对应着一个具体的 SKU 商品，包含着标题和金额，如现在的课程、会员服务。在订单域中的商品实体并不等同域商品域中的实体，比如可以将优惠券做成可以被售卖的商品，coupon_no 就是 product_key，具有 non-consumable 属性；或者将付费咨询的用户服务打包成商品售卖，那么 member_id 就能映射成 producer_key，并且觉有 consumable 属性。界限上下文就是区分不同领域下的领域对象，划定了领域对象含义的边界。在订单域中，商品实体默认可以是商品系统 SKU，也可以是优惠券和用户服务等。

上下文映射图

上下文映射图就通过画图的方式展示N（N>=2）个上下文之间的映射关系。

ACL表示防腐层，OHS表示开放主机服务，PL表示发布语言，U代表上游，D代表下游。

领域服务

你是否遇到过这样的问题：想建模一个领域概念，把它放在实体上不合适，把它放在值对象上也不合适，然后你冥思苦想着自己的建模方式是不是出了问题。恭喜你，祝贺你，你的建模手法完全没有问题，只是你还没有接触到领域服务（Domain Service）这个概念，因为领域服务本来就是来处理这种场景的。比如，要对客户端类型和版本进行判断是否支持某一项功能，我们可以创建一个 ClientVersionService 来负责。
值得一提的是，领域服务和上文中提到的应用服务是不同的，领域服务是领域模型的一部分，而应用服务不是。应用服务是领域服务的客户，它将领域模型变成对外界可用的软件系统。

领域事件

在DDD中，领域事件便可以用于处理上述问题，此时最终一致性取代了事务一致性，通过领域事件的方式达到各个组件之间的数据一致性。领域事件的命名遵循英语中的“名词+动词过去分词”格式，即表示的是先前发生过的一件事情。比如，购买者提交商品订单之后发布 OrderCreated 事件，用户支付 TradePaid 事件。需要注意的是，既然是领域事件，他们便应该从领域模型中发布。领域事件的最终接收者可以是本限界上下文中的组件，也可以是另一个限界上下文。
领域事件的额外好处在于它可以记录发生在软件系统中所有的重要修改，这样可以很好地支持程序调试和商业智能化。另外，在CQRS架构的软件系统中，领域事件还用于写模型和读模型之间的数据同步。再进一步发展，事件驱动架构可以演变成事件源（Event Sourcing），即对聚合的获取并不是通过加载数据库中的瞬时状态，而是通过重放发生在聚合生命周期中的所有领域事件完成。

实体 & 值对象 & 聚合 & 聚合根

实体 & 值对象

实体和值对象是组成领域模型的基础单元。
在 DDD 中有这样一类对象，它们拥有唯一标识符，且标识符在历经各种状态变更后仍能保持一致。对这些对象而言，重要的不是其属性，而是其延续性和标识，对象的延续性和标识会跨越甚至超出软件的生命周期。我们把这样的对象称为实体。
通过对象属性值来识别的对象，它将多个相关属性组合为一个概念整体。在 DDD 中用来描述领域的特定方面，并且是一个没有标识符的对象，叫作值对象。值对象本质就是一个集合，可以保证属性归类的清晰和概念的完整性。

举例说明

消费者实体原本包括：ID、昵称、注册手机号、姓名以及人员所在的省、市、县和街道等属性。这样显示地址相关的属性就很零碎了对不对？现在，我们可以将“省、市、县和街道等属性”拿出来构成一个“地址属性集合”，这个集合就是值对象了。

聚合 & 聚合根

聚合是业务和逻辑紧密关联的实体和值对象组合而成，聚合是数据修改和持久化的基本单元，一个聚合对应一个数据的持久化。聚合在DDD分层架构中属于领域层，领域层包含了多个聚合，共同实现核心业务逻辑，聚合内的实体以充血模型实现个体业务能力，以及业务逻辑的高内聚。跨多个实体的业务逻辑通过领域服务来实现，跨多个聚合的业务逻辑通过应用服务来实现。
如果把聚合比作组织，聚合根则是组织的负责人，聚合根也叫做根实体，它不仅仅是实体，还是实体的管理者。聚合之间通过聚合根关联引用，如果需要访问其他聚合的实体，先访问聚合根，再导航到聚合内部的实体。即外部对象不能直接访问聚合内的实体。

举例说明

上图说明聚合与聚合根的关系，交易聚合有一个唯一的聚合根交易单，交易单组织了消费者实体、商品实体、商铺实体、优惠券实体同时消费金额之对象。下面具体对比说明下：

聚合的特点：高内聚、低耦合，它是领域模型中最底层的边界，可以作为拆分微服务的最小单位，但我不建议你对微服务过度拆分。但在对性能有极致要求的场景中，聚合可以独立作为一个微服务，以满足版本的高频发布和极致的弹性伸缩能力。
一个微服务可以包含多个聚合，聚合之间的边界是微服务内天然的逻辑边界。有了这个逻辑边界，在微服务架构演进时就可以以聚合为单位进行拆分和组合了，微服务的架构演进也就不再是一件难事了。
聚合根的特点：聚合根是实体，有实体的特点，具有全局唯一标识，有独立的生命周期。一个聚合只有一个聚合根，聚合根在聚合内对实体和值对象采用直接对象引用的方式进行组织和协调，聚合根与聚合根之间通过 ID 关联的方式实现聚合之间的协同。
实体的特点：有 ID 标识，通过 ID 判断相等性，ID 在聚合内唯一即可。状态可变，它依附于聚合根，其生命周期由聚合根管理。实体一般会持久化，但与数据库持久化对象不一定是一对一的关系。实体可以引用聚合内的聚合根、实体和值对象。
值对象的特点：无 ID，不可变，无生命周期，用完即扔。值对象之间通过属性值判断相等性。它的核心本质是值，是一组概念完整的属性组成的集合，用于描述实体的状态和特征。值对象尽量只引用值对象。

防腐层

通过在遗留系统和现代系统之间使用防腐层来隔离它们。该层转换两个系统之间的通信，允许遗留系统保持不变，同时可以避免损害现代应用程序的设计和技术方法。

现代应用与防腐层之间的通信始终使用应用程序的数据模型和架构。从防腐层到遗留系统的调用都符合该系统的数据模型或方法。 防腐层包含两个系统之间转换所需的所有逻辑。该层可以作为应用程序中的组件或作为独立服务来实现。

贫血模型

贫血模型就是模型对象之间存在完整的关联(可能存在多余的关联)，但是对象除了get和set方外外几乎就没有其它的方 法，整个对象充当的就是一个数据容器，用C语言的话来说就是一个结构体，所有的业务方法都在一个无状态的Service类中实现，Service类仅仅包 含一些行为。
贫血模型的优点是很明显的：

  1. 被许多程序员所掌握，许多教材采用的是这种模型，对于初学者，这种模型很自然，甚至被很多人认为是java中最正统的模型。
  2. 它非常简单，对于并不复杂的业务(转帐业务)，它工作得很好，开发起来非常迅速。它似乎也不需要对领域的充分了解，只要给出要实现功能的每一个步骤，就能实现它。
  3. 事务边界相当清楚，一般来说service的每个方法都可以看成一个事务，因为通常Service的每个方法对应着一个用例。（在这个例子中我使用了facade作为事务边界，后面我要讲这个是多余的)
    其缺点为也是很明显的：
  4. 所有的业务都在service中处理，当业越来越复杂时，service会变得越来越庞大，最终难以理解和维护。
  5. 将所有的业务放在无状态的service中实际上是一个过程化的设计，它在组织复杂的业务存在天然的劣势，随着业务的复杂，业务会在service中多个方法间重复。
  6. 当添加一个新的UI时，很多业务逻辑得重新写。例如，当要提供Web Service的接口时，原先为Web界面提供的service就很难重用，导致重复的业务逻辑（在贫血模型的分层图中可以看得更清楚），如何保持业务逻辑一致是很大的挑战。

领域模型

领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。
领域驱动模型，与贫血模型相反，领域模型要承担关键业务逻辑，业务逻辑在多个领域对象之间分配，而Service只是完成一些不适合放在模型中的业务逻辑，它是非常薄的一层，它指挥多个模型对象来完成业务功能。
其优点是：

  1. 领域模型采用OO设计，通过将职责分配到相应的模型对象或Service，可以很好的组织业务逻辑，当业务变得复杂时，领域模型显出巨大的优势。
  2. 当需要多个UI接口时，领域模型可以重用，并且业务逻辑只在领域层中出现，这使得很容易对多个UI接口保持业务逻辑的一致(从领域模型的分层图可以看得更清楚)。
    其缺点是：
  3. 对程序员的要求较高，初学者对这种将职责分配到多个协作对象中的方式感到极不适应。
  4. 领域驱动建模要求对领域模型完整而透彻的了解，只给出一个用例的实现步骤是无法得到领域模型的，这需要和领域专家的充分讨论。错误的领域模型对项目的危害非常之大，而实现一个好的领域模型非常困难。
  5. 对于简单的软件，使用领域模型，显得有些杀鸡用牛刀了。

开放主机服务

该模式可以通过REST实现。通常来讲，我们可以将开放主机服务看作是远程过程调用（RPC）的API。同时，也可以通过消息机制实现。

参考

https://www.cnblogs.com/snidget/p/12995676.html
https://zhuanlan.zhihu.com/p/130945830
https://blog.csdn.net/itfly8/article/details/109554847
https://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html
https://iambowen.gitbooks.io/cloud-design-pattern/content/patterns/anti-corruption-layer.html

发表于

关注树莓派很久了，只是没有很感兴趣的应用场景，就没有买来玩。几个月前偶然得到一个小度音箱，发现了新大陆，各种语音控制功能，便捷性不言而喻，还买了一些外部设备可以通过小度控制，发现有红外遥控器可以控制家里的大部分红外家电，奈何码库不是很全，有些设备还是不能控制的，而且不支持定制功能。恰好在知乎看到了一些 geek 视频，想着自己也做一个，可以支持红外数据的定制，做到自由遥控。于是乎说干就干，从一个什么硬件都不懂的小白一步步的了解了点硬件知识，软件部分相对好实现一些。主要计划的功能是通过语音来控制红外家电、温湿度监控以及智能提醒等功能，先完成主体框架然后再不断开发插件形式来增强可玩性。

计划主要分为两个子系统：

  1. 软件子系统，主要实现语音到文字和文字到语音的转换，逻辑功能的处理等。
  2. 硬件子系统提供收音、音箱、温湿度传感器、红外收发、系统供电等能力的支持。

总体功能点进度如下：

  • ok 显示，信息简单展示界面，计划采用 OLED12832 屏。
  • ok 收音，收集外接语音信息。
  • ok 音响，输出系统响应结果。
  • 温湿度，收集设备所处环境的温度和湿度。
  • ok 风扇，硬件系统散热。
  • ok 红外收/发，红外设备系统的录入和红外信号的发射，用于控制红外家电。
  • 供电模块，给音响和树莓派硬件供电。
  • ok pcb 电路版设计，传感器集成。
  • 3d 打印外壳，最后根据硬件的排列情况定制一个简洁的外壳。
  • ok 语音汉字互转，计划采用讯飞 API 接口实现，后面尝试做简单的语音识别模型。
  • ok 逻辑控制和输出输入设备控制模块，基于硬件传感器数据的采集和信息的归纳整理能力。

硬件部分

一直以来都是做的软件，这次从 0 到 1 一点点学的硬件，到 PCB 打样，焊板。没有遵循设计规范，只是按照能用的级别做的。

v0.2

实验数据收集

树莓派4 GPIO 引脚

一、电源输出引脚

3v3、5v代表：3.3伏特和5伏特，是输出供电的正极，也就是我们常说的Vcc

GND代表接地和输出供电的负极

特别注意：每个引脚最大输出电流为16毫安(mA)，且同一时刻所有引脚的总输出电流不超过51毫安

二、GPIO

GPIO（General Purpose I/O Ports）意思为通用输入/输出端口，通俗地说，就是一些引脚，可以通过它们输出高低电平或者通过它们读入引脚的状态-是高电平或是低电平。GPIO是个比较重要的概念，用户可以通过GPIO口和硬件进行数据交互（如UART），控制硬件工作（如LED、蜂鸣器等），读取硬件的工作状态信号（如中断信号）等。GPIO口的使用非常广泛。掌握了GPIO，差不多相当于掌握了操作硬件的能力。树莓派有26个GPIO接口，其中有一部分是复用接口。

  1. 引脚3、5为IC总线复用接口
  2. 引脚7为（GCLK）全局时钟引脚复用接口
  3. 引脚19、21、23为SPI总线复用接口
  4. 引脚8、10为串口复用接口，TX发送，RX接收
  5. 引脚12、32、33、35为PWM复用接口

三、IC总线

IC是内部整合电路的称呼，是一种串行通讯总线，使用多主从架构，由飞利浦公司在1980年代为了让主板、嵌入式系统或手机用以连接低速周边装置而发展。IC的正确读法为”Inter－Integrated Circuit” 。

  • SDA：数据线
  • SCL：时钟线

四、SPI总线

SPI是串行外设接口（Serial Peripheral Interface）的缩写，是一种高速的，全双工，同步的通信总线，并且在芯片的管脚上只占用四根线，节约了芯片的管脚，同时为PCB的布局上节省空间，提供方便，正是出于这种简单易用的特性，如今越来越多的芯片集成了这种通信协议。

  • MISO：数据输入
  • MOSI：数据输出
  • SCLK：时钟信号
  • SS：使能信号

五、UART总线

UART是一种通用串行数据总线，用于异步通信。该总线双向通信，可以实现全双工传输和接收。在嵌入式设计中，UART用于主机与辅助设备通信，如汽车音响与外接AP之间的通信，与PC机通信包括与监控调试器和其它器件，如EEPROM通信。
可以理解为计算机的串口。RS232、TTL。

  • RX是接收
  • TX是发送

六、PWM脉冲宽度调制

脉冲宽度调制是一种模拟控制方式，其根据相应载荷的变化来调制晶体管基极或MOS管栅极的偏置，来实现晶体管或MOS管导通时间的改变，从而实现开关稳压电源输出的改变。这种方式能使电源的输出电压在工作条件变化时保持恒定，是利用微处理器的数字信号对模拟电路进行控制的一种非常有效的技术。脉冲宽度调制是利用微处理器的数字输出来对模拟电路进行控制的一种非常有效的技术，广泛应用在从测量、通信到功率控制与变换的许多领域中。

AD 教程

AD 使用与硬件电路图画图和PCB图设计使用的。主要是看了B站的一个入门视频教程，然后再不断搜搜改改来实现的。

https://blog.csdn.net/wxh0000mm/article/details/70237722
https://www.bilibili.com/video/av94518044?p=1
https://www.zhihu.com/question/32069273

单位转换

  • 1.0mil = 0.025mm
  • 1.2mil = 0.030mm
  • 1.25mil = 0.032mm

DHT11 温湿度传感器

下面是温湿度传感器的基本电路图，这里本来是3pin方案到树莓派的，板子上也画好了，只不过在焊接的时候没有处理好，现在系统始终无法正确读数，只是在测试期间能正常读。

https://shumeipai.nxez.com/2019/10/06/reading-temperature-and-humidity-from-dht11-with-raspberry-pi.html

OLED 12832

这里使用了 Adafruit_Python_SSD1306 库来驱动液晶屏显示。

https://shumeipai.nxez.com/2019/04/29/use-the-ssd1306-oled-display-on-the-raspberry-pi.html

IR 收发

红外发射图，这里只画了两个，实际我是配置了4个红外发射二极管，限流电阻调整成 100R。

红外接收图，这里直接使用已经简单封装的传感器

IR的收发是主要调试的功能：

红外录入功能使用：
安装 Linux 下的红外控制库：

1
2
sudo apt-get update
sudo apt-get install lirc

更新 /boot/config.txt 文件来开启红外收发接口：

1
2
# Uncomment this to enable the lirc-rpi module
dtoverlay=lirc-rpi,gpio_out_pin=17,gpio_in_pin=18,gpio_in_pull=up

更新 /etc/lirc/lirc_options.conf 文件来控制当前是接收模式还是发射模式，修改完重启服务生效：

1
device=/dev/lirc0

测试能否正常接收到红外信号：

1
2
3
4
5
6
7
8
mode2 -d /dev/lirc0

space 16777215
pulse 8999
space 4457
pulse 680
space 1627
......

可以通过 lirc 录制简单的红外设备生成遥控文件，如果空调这种比较复杂的不太好弄。

1
2
3
4
5
6
7
# 查看按键名称，这里一个红外码是绑定到一个按键上的，你需要找一些你录制的按键然后记下来。
irrecord -l
# 开启录制命令，这个录制过程比较复杂，需要先判断环境噪音，然后随机按键，最后才是录制按键，而我的有些红外设备按键无法录上有点奇怪，目前只有台灯的录进去了。
irrecord ~/lircd.conf
# 如果有问题可以录制 raw code
irrecord -f ~/lircd.conf

录制好的文件内容像下面这样，如果没有内容则说明没有录制上。

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
begin remote
  name myir
  flags RAW_CODES|CONST_LENGTH
  eps 30
  aeps 100
  gap 108055
      begin raw_codes
          name KEY_1
            9062 4462 621 531 627 532
              626 531 626 532 629 531
              601 556 627 531 628 530
              628 1610 629 1611 603 1636
              603 1636 629 1612 629 1609
              631 1609 630 1610 627 1612
              630 530 629 1608 629 532
              626 534 625 532 628 1609
              629 532 628 529 630 1609
              629 530 626 1612 629 1610
              629 1610 629 540 633 1596
              629
          name KEY_2
            9067 4455 632 528 630 528
              633 524 631 529 630 529
              630 528 630 530 630 528

最后要把录制的文件内容复制到对应目录，重启，让 lirc 服务能加载上：

1
sudo cp ~/xx.lircd.conf /etc/lirc/lircd.d/xx.lircd.conf

实际上发送按键需要执行的命令包含你复制的文件名（device-name）以及按键名（KEY_1）：

1
irsend SEND_ONCE <device-name> KEY_1

红外输入输出参考

https://www.pythonheidong.com/blog/article/191812/
https://www.jianshu.com/p/96f16846dfa3
https://segmentfault.com/a/1190000014135418
https://www.jianshu.com/p/9cfb0bf02006
https://www.cnblogs.com/huanglufei/articles/5562330.html
https://www.jianshu.com/p/abdcd3e06726

软件部分

简单的将软件部分分为前台功能和后台功能，前台功能主要是面向用户使用层面，后台功能主要是配置相关功能。

前台功能分为三个模块，输入模块、逻辑处理模块和输出模块。

其中热词唤醒方案使用的 snowboy ，语音文字互转采用的讯飞免费接口，后面可以考虑实现一些简单的部分。

按照这个方案，后续只要不断配置和扩展功能即可，主要处理流程不会有太大变化产生。

语音部分参考

https://www.jianshu.com/p/a1c06020f5fd
https://www.cnblogs.com/lovesKey/p/11080448.html
https://www.cnblogs.com/DragonFire/p/9212935.html
https://www.xfyun.cn/doc/asr/voicedictation/API.html
https://www.xfyun.cn/doc/tts/online_tts/API.html
https://www.xfyun.cn/doc/asr/voicedictation/Audio.html

软件部分目前不打算公开，主要写的太烂。等优化后再放出来。

总结

目前一期实现了核心部分的功能，可以语音控制普通红外家电，耗时有两周（晚上），目前的时间精力上也只能做到这样，毕竟工作和生活还要占据绝大部分时间的。使用上流程比较简单，插电开机自启动后就可以了，只是语音和音箱部分还没有很方便的集成到整个项目里面。下一期做的时候计划优化电路，支持更多的传感器，然后把麦和音箱集成进去，再做一个外壳。
整个项目从计划到实施还是学到了一些，主要是硬件方面上的了解，电路原理图、PCB画图打样、硬件电路 IO 接口标准等，软件部分并没有太多的实践，准备放到三期做软件层面的优化，把外部 API 调用改成自己训练的语音模型。

发表于

环境

1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE `people` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(16) DEFAULT NULL,
  `pass` varchar(256) DEFAULT NULL,
  `card` varchar(32) DEFAULT NULL,
  `age` int(11) NOT NULL,
  `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `card_UNIQUE` (`card`),
  KEY `name_age_key` (`name`,`age`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

插入十一万条随机数据

1
INSERT INTO `people` (`name`,`pass`,`card`,`age`) VALUES ('强欣笑','eSbJgrXAVjEy','143185791961386356',53), ... ;

EXPLAIN 查询计划

https://www.cnblogs.com/DataArt/p/10215663.html

OPTIMIZER_TRACE 使用

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
-- 1. 打开 optimizer_trace功能，默认是关着的
SHOW VARIABLES LIKE 'optimizer_trace';
SET optimizer_trace="enabled=on";

-- 2. 执行查询
SELECT name,
		 count(*) cnt,
		 group_concat(distinct card) gd_card
FROM people
WHERE age > 10
		AND age > -1
		AND 1=1
		AND age < 99
GROUP BY  name
HAVING cnt > 1
ORDER BY  cnt DESC limit 20000;

-- 3. 从OPTIMIZER_TRACE表中查看上一个查询的优化过程
SELECT * FROM information_schema.OPTIMIZER_TRACE;

-- 4. 还要用的话就重复2、3
-- ...

-- 5. 不用了就关掉
SET optimizer_trace="enabled=off";

解读

MySQL分为以上几个模块，主要是 server 层和存储引擎层，service 层又分为连接器、分析器、优化器、执行器和查询缓存几个部分。

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
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
{
    "steps": [
        {
            "join_preparation": {
                "select#": 1,
                "steps": [
                    {
                        "expanded_query": "/* select#1 */ select `people`.`name` AS `name`,count(0) AS `cnt`,group_concat(distinct `people`.`card` separator ',') AS `gd_card` from `people` where ((`people`.`age` > 10) and (`people`.`age` > -(1)) and (1 = 1) and (`people`.`age` < 99)) group by `people`.`name` having (`cnt` > 1) order by `cnt` desc limit 20000"
                    }
                ]
            }
        },
        {
            "join_optimization": {
                "select#": 1,
                "steps": [
                    {
                        // 处理搜索条件
                        "condition_processing": {
                            "condition": "WHERE",
                            // 原始搜索条件
                            "original_condition": "((`people`.`age` > 10) and (`people`.`age` > -(1)) and (1 = 1) and (`people`.`age` < 99))",
                            "steps": [
                                {
                                    // 等值传递转换
                                    "transformation": "equality_propagation",
                                    "resulting_condition": "((`people`.`age` > 10) and (`people`.`age` > -(1)) and (1 = 1) and (`people`.`age` < 99))"
                                },
                                {
                                    // 常量传递转换
                                    "transformation": "constant_propagation",
                                    "resulting_condition": "((`people`.`age` > 10) and (`people`.`age` > -(1)) and (1 = 1) and (`people`.`age` < 99))"
                                },
                                {
                                    // 去除没用的条件
                                    "transformation": "trivial_condition_removal",
                                    "resulting_condition": "((`people`.`age` > 10) and (`people`.`age` > -(1)) and (`people`.`age` < 99))"
                                }
                            ]
                        }
                    },
                    {
                        "condition_processing": {
                            "condition": "HAVING",
                            "original_condition": "(`cnt` > 1)",
                            "steps": [
                                {
                                    "transformation": "constant_propagation",
                                    "resulting_condition": "(`cnt` > 1)"
                                },
                                {
                                    "transformation": "trivial_condition_removal",
                                    "resulting_condition": "(`cnt` > 1)"
                                }
                            ]
                        }
                    },
                    {
                        // 替换虚拟生成列
                        "substitute_generated_columns": {}
                    },
                    {
                        // 表的依赖信息
                        "table_dependencies": [
                            {
                                "table": "`people`",
                                "row_may_be_null": false,
                                "map_bit": 0,
                                "depends_on_map_bits": []
                            }
                        ]
                    },
                    {
                        "ref_optimizer_key_uses": []
                    },
                    {
                        // 预估不同单表访问方法的访问成本
                        "rows_estimation": [
                            {
                                "table": "`people`",
                                "const_keys_added": {
                                    "keys": [
                                        "name_age_key"
                                    ],
                                    "cause": "group_by"
                                },
                                "range_analysis": {
                                    // 全表扫描的行数及成本
                                    "table_scan": {
                                        "rows": 109674,
                                        "cost": 22482
                                    },
                                    // 分析可能使用的索引
                                    "potential_range_indexes": [
                                        {
                                            "index": "PRIMARY",
                                            "usable": false,
                                            "cause": "not_applicable"
                                        },
                                        {
                                            "index": "card_UNIQUE",
                                            "usable": false,
                                            "cause": "not_applicable"
                                        },
                                        {
                                            "index": "name_age_key",
                                            "usable": true,
                                            "key_parts": [
                                                "name",
                                                "age",
                                                "id"
                                            ]
                                        }
                                    ],
                                    "setup_range_conditions": [],
                                    "group_index_range": {
                                        "chosen": false,
                                        "cause": "not_applicable_aggregate_function"
                                    },
                                    // 分析各种可能使用的索引的成本
                                    "analyzing_range_alternatives": {
                                        "range_scan_alternatives": [
                                            {
                                                "index": "name_age_key",
                                                "chosen": false,
                                                "cause": "unknown"
                                            }
                                        ],
                                        "analyzing_roworder_intersect": {
                                            "usable": false,
                                            "cause": "too_few_roworder_scans"
                                        }
                                    }
                                }
                            }
                        ]
                    },
                    {
                        "considered_execution_plans": [
                            {
                                "plan_prefix": [],
                                "table": "`people`",
                                "best_access_path": {
                                    "considered_access_paths": [
                                        {
                                            "rows_to_scan": 109674,
                                            "access_type": "scan",
                                            "resulting_rows": 4060.8,
                                            "cost": 22480,
                                            "chosen": true
                                        }
                                    ]
                                },
                                "condition_filtering_pct": 100,
                                "rows_for_plan": 4060.8,
                                "cost_for_plan": 22480,
                                "chosen": true
                            }
                        ]
                    },
                    {
                        // 尝试给查询添加一些其他的查询条件
                        "attaching_conditions_to_tables": {
                            "original_condition": "((`people`.`age` > 10) and (`people`.`age` > -(1)) and (`people`.`age` < 99))",
                            "attached_conditions_computation": [],
                            "attached_conditions_summary": [
                                {
                                    "table": "`people`",
                                    "attached": "((`people`.`age` > 10) and (`people`.`age` > -(1)) and (`people`.`age` < 99))"
                                }
                            ]
                        }
                    },
                    {
                        "clause_processing": {
                            "clause": "ORDER BY",
                            "original_clause": "`cnt` desc",
                            "items": [
                                {
                                    "item": "count(0)"
                                }
                            ],
                            "resulting_clause_is_simple": false,
                            "resulting_clause": "`cnt` desc"
                        }
                    },
                    {
                        "clause_processing": {
                            "clause": "GROUP BY",
                            "original_clause": "`people`.`name`",
                            "items": [
                                {
                                    "item": "`people`.`name`"
                                }
                            ],
                            "resulting_clause_is_simple": true,
                            "resulting_clause": "`people`.`name`"
                        }
                    },
                    {
                        "reconsidering_access_paths_for_index_ordering": {
                            "clause": "GROUP BY",
                            "steps": [],
                            "index_order_summary": {
                                "table": "`people`",
                                "index_provides_order": true,
                                "order_direction": "asc",
                                "index": "name_age_key",
                                "plan_changed": true,
                                "access_type": "index"
                            }
                        }
                    },
                    {
                        "refine_plan": [
                            {
                                "table": "`people`"
                            }
                        ]
                    },
                    {
                        "creating_tmp_table": {
                            "tmp_table_info": {
                                "table": "intermediate_tmp_table",
                                "row_length": 130,
                                "key_length": 0,
                                "unique_constraint": false,
                                "location": "memory (heap)",
                                "row_limit_estimate": 129055
                            }
                        }
                    },
                    {
                        "sort_using_internal_table": {
                            "condition_for_sort": "(`cnt` > 1)",
                            "having_after_sort": null
                        }
                    }
                ]
            }
        },
        {
            "join_execution": {
                "select#": 1,
                "steps": [
                    {
                        "creating_tmp_table": {
                            "tmp_table_info": {
                                "table": "intermediate_tmp_table",
                                "row_length": 84,
                                "key_length": 0,
                                "unique_constraint": false,
                                "location": "disk (InnoDB)",
                                "record_format": "packed"
                            }
                        }
                    },
                    {
                        "filesort_information": [
                            {
                                "direction": "desc",
                                "table": "intermediate_tmp_table",
                                "field": "cnt"
                            }
                        ],
                        "filesort_priority_queue_optimization": {
                            "usable": false,
                            "cause": "not applicable (no LIMIT)"
                        },
                        "filesort_execution": [],
                        "filesort_summary": {
                            // 排序过程中持有的行数
                            "rows": 27045,
                            // 参与排序的行数，InnoDB 返回的行数
                            "examined_rows": 34054,
                            // 排序使用的临时文件数量
                            "number_of_tmp_files": 24,
                            // 内存排序使用的内存大小
                            "sort_buffer_size": 25744,
                            // 排序模式 
                            "sort_mode": "<sort_key, rowid>"
                        }
                    }
                ]
            }
        }
    ]
}

优化过程大致分为了三个阶段：

prepare阶段

optimize阶段

execute阶段

我们所说的基于成本的优化主要集中在optimize阶段，对于单表查询来说，我们主要关注optimize阶段的”rows_estimation”这个过程，这个过程深入分析了对单表查询的各种执行方案的成本；对于多表连接查询来说，我们更多需要关注”considered_execution_plans”这个过程，这个过程里会写明各种不同的连接方式所对应的成本。反正优化器最终会选择成本最低的那种方案来作为最终的执行计划，也就是我们使用EXPLAIN语句所展现出的那种方案。

参考

https://www.cnblogs.com/taosiyu/p/13206378.html

发表于

这个标题看起有点鸡汤文，不过我还是建议对以下总结出的几点做些深入思考，这些会在今后的工作中越来越多的感受到它的作用。

寻找你行业内的专家

找到你所属行业内的专家，这些人往往做事高效并且很有才华。你要做的是跟随他们所关注的方向，学习他们做事的方法，思考如何应用到你的工作和生活上。找到他们，和他们去交流思考，提出自己的观点和想法。不要仅仅把眼光放到身边的人身上，这样会局限住你的视野。

每天都写新代码

工作重复枯燥？也许有时候我们只是懒得思考，用最顺手的方式把工作做完，容易形成惯性思维。为什么会有很多的复制粘贴？简单的修改来适配当前需求，这里我们更需要的是想想能不能把这段逻辑抽象出来变得更通用，整个模块的设计是否不够合理，多想一想多做一点，下一次再来需求也许可以提升十倍的效率。

底层的原理更重要

客观的说，更快进步的方法之一是忽略掉那些并不能提高技能的东西，比如语言语法和配置工具，这些技能属于“知其然”，而你更需要的是“知其所以然”。有一次去医院科室挂号使用的是先到先叫的模式，而在急诊室挂号是按照轻重缓急分成四个等级的，危重病人优先抢救的模式。这不就和操作系统中的任务调度概念是一样的，优先级调度模式，这些底层的概念才是一通百通真正提高帮助你的东西。我在尝试去找行业经典论文看。

学会调研

作为程序员会比较容易脑子一热，有一个想法很容易趁热着急写代码，但往往缺乏思考写出来的代码不能尽如人意。这时候你更需要的是慢下来，好好思考一下，也许这些别人已经做过，有更好的方案，看看别人是如何做的。先调研再实施，这样会彻底改变你解决问题的思路。

学好英语

真的是这样，如果你英语不好，那么会比别人走更多的弯路，就像走在密林深处看不清路一样。不得不承认很多优秀框架的官方文档还是英文为主，如果再经过翻译里面的很多语义语境会丢失，在项目的社区中，你还能与作者们去交流你学习中遇到的问题。

如何去做

说了这么多，看着就好像道理我都懂，但是我不知道怎么做。我这里先总结几个点，也是自己在不断尝试学习的方法。

  1. 看行业经典论文，比如 mapreduce、raft 这些都是一通百通的底层概念。
  2. 研究优秀框架的源代码，理解核心原理，尝试造轮子。
  3. 每天学英语，尝试在开源社区与作者们进行互动。
  4. 找到一两位行业专家，向他们学习和请教问题。
  5. 坚持以上几点。

end.

发表于

ORM（Object/Relational Mapper），即“对象-关系型数据映射组件”。对于O/R，即 Object（对象）和Relational（关系型数据），表示必须同时使用面向对象和关系型数据进行开发。本文简述通过 Java 动态代理机制实现关系数据与 POJO 对象的映射。

代理

静态代理

静态代理其实就是指设计模式中的代理模式。
代理模式为其他对象提供一种代理以控制对这个对象的访问。

静态代理模式在增强现有的接口业务功能方面有很大的优点，但是大量使用这种静态代理，会使我们系统内的类的规模增大，并且不易维护。

动态代理

为了解决静态代理的问题，引入动态代理的概念，在编译时或者运行时，可以在需要代理的地方动态生成代理，减轻代理类和类在系统中冗余的问题。

Java 动态代理基于经典代理模式，引入了一个 InvocationHandler，InvocationHandler 负责统一管理所有的方法调用。

InvocationHandler

InvocationHandler 接口定义：

1
2
3
4
public interface InvocationHandler {
	public Object invoke(Object proxy, Method method, Object[] args)
	        throws Throwable;
}

每一个动态代理类都必须要实现 InvocationHandler 这个接口，通过代理类的实例调用一个方法时，这个方法的调用就会被转发为由 InvocationHandler 这个接口的 invoke 方法来进行调用。

Proxy

Proxy 这个类的作用就是用来动态创建一个代理对象的类，它提供了许多的方法，但是我们用的最多的就是 newProxyInstance 这个方法，可以获得一个动态的代理对象：

1
public static Object newProxyInstance(ClassLoader loader, Class<?>[] interfaces,  InvocationHandler h)  throws IllegalArgumentException

实现

参照 mybaits 的用法实现基本的映射能力。

注解

首先定义了三个注解，一个作用在类上 DaoMapper 作用在类上标记这是一个映射类，然后定义注解 Selector 作用在方法上标记查询作用，定义注解 Param 作用在参数上为预编译位的映射。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
@Documented
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface DaoMapper {
}

@Documented
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Selector {
    String value();
}

@Documented
@Target(ElementType.PARAMETER)
@Retention(RetentionPolicy.RUNTIME)
public @interface Param {
    String value();
}

定义一个实体类，与数据库的表字段映射上。增强 feature 可以自动做驼峰转换，这里没有实现。

1
2
3
4
5
6
7
8
9
@Data
public class BaseLineModel {
    public static final String TABLE = "baseline";

    private Integer id;
    private String report_name;
    private Integer report_period;
    private LocalDateTime creation_date;
}

定义dao层接口，加上注解

1
2
3
4
5
6
7
@DaoMapper
public interface BaseLineDao {

    @Selector("select * from "+ BaseLineModel.TABLE +" where report_name = #{reportName}")
    BaseLineModel select(@Param("reportName") String report_name);
}

JDBC OP

做到一个很简单的 JDBC 操作工具类，字段映射处理也写到了这里。实现了查询操作，将入参 sql template 以及参数按顺序传入，生成 prepareStatement 后执行，再将返回结果映射到 model 对象。这里的连接池管理、自动重连、配置管理等增强 features 非重点，不做实现。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
/**
    * 查询
    * @param clazz model类
    * @param sql
    * @param params
    * @param <T>
    * @return
    */
public <T> T query(Class<T> clazz, String sql, Object... params) throws SQLException, IllegalAccessException, NoSuchMethodException, InvocationTargetException, InstantiationException {
    Object model =  clazz.newInstance();
    try (Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/cat", "root", "123456")) {
        PreparedStatement statement = conn.prepareStatement(sql);
        int flag = 1;
        for (Object obj : params) {
            setValue(statement, flag, obj);
            flag++;
        }
        ResultSet resultSet = statement.executeQuery();
        resultSet.afterLast();
        resultSet.previous();
        fullRes(resultSet, model);
    }
    return (T) model;
}

映射函数，通过自动寻找 setter 方法填充结果，这里只实现了三种字段。

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
private static void fullRes(ResultSet resultSet, Object model) throws SQLException, InvocationTargetException, IllegalAccessException, NoSuchMethodException {
    Field[] declaredFields = model.getClass().getDeclaredFields();
    for (Field field : declaredFields) {
        String fieldName = field.getName();
        if (fieldName.toUpperCase().equals(fieldName)) {
            continue;
        }
        String setFuncName = "set" + fieldName.substring(0, 1).toUpperCase() + fieldName.substring(1);
        String fieldType = field.getGenericType().toString();

        Object object = resultSet.getObject(fieldName);
        if (fieldType.equals("class java.lang.String")) {
            Method m = model.getClass().getMethod(setFuncName, String.class);
            m.invoke(model, object);
        } else if (fieldType.equals("class java.lang.Integer")) {
            Method m = model.getClass().getMethod(setFuncName, Integer.class);
            m.invoke(model, object);
        } else if (fieldType.equals("class java.time.LocalDateTime")) {
            Method m = model.getClass().getMethod(setFuncName, LocalDateTime.class);
            if (object instanceof Timestamp) {
                object = ((Timestamp) object).toLocalDateTime();
            }
            m.invoke(model, object);
        }
    }
}

动态代理部分

定义一个 MapperMethod 类，实例化的时候提取接口方法的注解信息解析成 JDBC 需要的参数以及记录接口方法的返回对象， execute 执行。

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

public class MapperMethod<T> {
    private String sql;
    private Class<?> resType;
    private int[] paramsIndex;


    public MapperMethod(Method method) {
        this.resType = method.getReturnType();
        String sourceSql = method.getAnnotation(Selector.class).value();
        Parameter[] parameters = method.getParameters();
        int flag = 0;
        this.paramsIndex = new int[parameters.length];
        for (Parameter parameter: parameters) {
            String paramName = parameter.getAnnotation(Param.class).value();
            String paramFullName = String.format("#{%s}", paramName);
            int indexOf = sourceSql.indexOf(paramFullName);
            this.paramsIndex[flag] = indexOf;
            flag++;
            this.sql = sourceSql.replace(paramFullName, "?");
        }
    }

    public Object execute(Object[] objects) {
        JdbcUtil jdbcUtil = new JdbcUtil();
        try {
            return jdbcUtil.query(this.resType, this.sql, objects);
        } catch (SQLException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        } catch (NoSuchMethodException e) {
            e.printStackTrace();
        } catch (InvocationTargetException e) {
            e.printStackTrace();
        } catch (InstantiationException e) {
            e.printStackTrace();
        }
        return null;
    }
}

定义动态代理类，在实例化的时候记录代理接口，以及代理方法类缓存，调用接口的时候会被动态代理到 invoke 函数执行，然后交由 MapperMethod 代理方法实例执行。

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
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.util.Map;
import java.util.Objects;

public class MapperProxy<T> implements InvocationHandler {

    private final Class<T> mapperInterface;

    private final Map<Method, MapperMethod> methodCache;

    public MapperProxy(Class<T> mapperInterface, Map<Method, MapperMethod> methodCache) {
        this.mapperInterface = mapperInterface;
        this.methodCache = methodCache;
    }

    @Override
    public Object invoke(Object o, Method method, Object[] objects) throws Throwable {
        MapperMethod mapperMethod = cachedMapperMethod(method);
        return mapperMethod.execute(objects);
    }

    private MapperMethod cachedMapperMethod(Method method) {
        MapperMethod mapperMethod = methodCache.get(method);
        if (Objects.isNull(mapperMethod)) {
            mapperMethod = new MapperMethod(method);
            methodCache.put(method, mapperMethod);
        }
        return mapperMethod;
    }
}

最后代理工厂类，接收被 DaoMapper 作用的接口，并通过 newInstance 方法创建代理类实例。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class MapperProxyFactory<T> {

    private final Class<T> mapperInterface;

    private Map<Method, MapperMethod> methodCache = new ConcurrentHashMap<>();

    public MapperProxyFactory(Class<T> mapperInterface) {
        if (Objects.isNull(mapperInterface.getAnnotation(DaoMapper.class))) {
            throw new RuntimeException("缺少注解 DaoMapper");
        }
        this.mapperInterface = mapperInterface;
    }


    public T newInstance() {
        final MapperProxy<T> mapperProxy = new MapperProxy<>(mapperInterface, methodCache);
        return (T) Proxy.newProxyInstance(mapperInterface.getClassLoader(), new Class[]{mapperInterface}, mapperProxy);
    }
}

执行，创建一个代理工厂，然后创建 BaseLineDao 的代理对象， 调用 select 方法，实际上调用到代理对象的 invoke 方法，然后交由 mapperMethod.execute 方法执行：

1
2
3
4
5
6
public static void main(String[] args) {
    MapperProxyFactory mapperProxyFactory = new MapperProxyFactory(BaseLineDao.class);
    BaseLineDao baseLineDao = (BaseLineDao) mapperProxyFactory.newInstance();
    BaseLineModel test1 = baseLineDao.select("TEST1");
    System.out.println(test1);
}

扩展

TODO：

  1. Java动态代理与 cglib 动态代理的异同点。
  2. 动态代理的实现原理。

总结

通过这个个简单的实践，了解了 Java 动态代理的使用方法以及对象关系数据的映射处理。

参考

https://zhuanlan.zhihu.com/p/60805342
https://www.zhihu.com/question/20794107/answer/658139129

发表于

锁解决的问题是并发操作引起的脏读、数据不一致问题。

基本原理

volatile

在Java中允许线程访问共享变量，为了确保共享变量能被准确和一致的更新，线程应该确保使用排它锁来单独获得这个变量，Java中提供了 volatile，使之在多处理器开发中保证变量的可见性，当一个线程改变了共享变量，另一个线程能够及时读到这个修改的值。恰当的使用它会比 synchronized 成本更低，因为不会引起上下文的切换和调度。

synchronized

通过锁机制实现同步，在Java中每一个对象都可以作为锁，有以下三种形式：

  • 对于普通同步方法，锁的是当前实例对象。
  • 对于静态同步方法，所得是当前类 class 对象。
  • 对于同步方法块，锁的是括号内指定的对象。

为了减少获得锁和释放锁带来的性能消耗，Java SE 1.6 引入了偏向锁和轻量级锁。偏向锁 的核心思想是：如果一个线程获得了锁，就进入偏向模式，当这个线程再次请求锁时，如果没有其它线程获取过该锁，无需再做任何同步操作，可以节省大量锁申请的操作，来提高性能。如果偏向锁获取失败，会通过 轻量级锁 的方式获取，如果获取成功则进入临界区，如果失败则表示有其它线程争夺到锁，当前线程锁请求会膨胀为 重量级锁 。

锁粗化 是指在遇到一连串连续的对同一个锁不断的进行请求和释放的操作时，会把所有的锁操作整合成对锁的一次请求，减少锁请求的同步次数。

锁消除 是指在编译期，通过对上下文的扫描，去除不可能存在共享资源竞争的锁。

自旋锁 是指在锁膨胀后，避免线程真正的在操作系统层面被挂起，通过对线程做几个空循环，以期望在这之后能获取到锁，顺利的进入临界区，如果还获取不到，则会真正被操作系统层面挂起。

CAS

指的是比较并交换，它是一个原子操作，比较一个内存位置的值并且只有相等时修改这个内存位置的值并更新值，保证新的值总是基于最新的信息计算的。在 JVM 中 CAS 操作是利用处理器提供的 CMPXCHS 指令实现。是实现我们平时所说的自旋锁或乐观锁的核心操作。

优点是竞争小的时候使用系统开销小；对应缺点是循环时间长开销大、ABA问题、只能保证一个变量的原子操作。

ABA 问题

问题产生原因是两个线程处理的时间差导致，具体如下图：

解决 ABA 问题可以增加一个版本号，在每次修改值的时候增加一个版本号。

产生：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
private static AtomicReference<Integer> atomicReference = new AtomicReference<Integer>(100);

public static void main(String[] args) {
    new Thread(() -> {
        atomicReference.compareAndSet(100, 101);
        atomicReference.compareAndSet(101, 100);
    },"t1").start();

    new Thread(() -> {
        try {
            TimeUnit.SECONDS.sleep(1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println(atomicReference.compareAndSet(100, 2019) + "\t修改后的值:" + atomicReference.get());
    },"t2").start();
}

解决：

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
private static AtomicStampedReference<Integer> atomicStampedReference = new AtomicStampedReference<Integer>(100,1);

public static void main(String[] args) {
    new Thread(() -> {
        System.out.println("t1拿到的初始版本号:" + atomicStampedReference.getStamp());

        //睡眠1秒，是为了让t2线程也拿到同样的初始版本号
        try {
            TimeUnit.SECONDS.sleep(1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        atomicStampedReference.compareAndSet(100, 101,atomicStampedReference.getStamp(),atomicStampedReference.getStamp()+1);
        atomicStampedReference.compareAndSet(101, 100,atomicStampedReference.getStamp(),atomicStampedReference.getStamp()+1);
    },"t1").start();

    new Thread(() -> {
        int stamp = atomicStampedReference.getStamp();
        System.out.println("t2拿到的初始版本号:" + stamp);

        //睡眠3秒，是为了让t1线程完成ABA操作
        try {
            TimeUnit.SECONDS.sleep(3);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("最新版本号:" + atomicStampedReference.getStamp());
        System.out.println(atomicStampedReference.compareAndSet(100, 2019,stamp,atomicStampedReference.getStamp() + 1) + "\t当前 值:" + atomicStampedReference.getReference());
    },"t2").start();
}

发表于

在 Chrome 上有个很好用的插件 FeHelper，应该是每个开发人员都在使用的，功能很全面。想着能不能搞个桌面版的，这样多屏环境下可以不用在众多 tab 页中找功能了。

桌面版实现，界面比较丑陋，不过用起来方便就行。这样可以在多屏环境下一个屏用来开啊，另一个屏可以观察辅助信息和使用小工具。

了解到 electron 是一个开源跨平台框架，可以使用 nodejs 做后端和 chromium 做前端开发。像 atom 和 vs code 使用这个框架开发的。觉得还是和方便的，主要是跨平台。而这个插件也是基于 nodejs 开发的，应该可以迁移过来。然后按照官方文档开发，通过 iframe load 不同页面。

项目地址：https://github.com/noogel/xyzToolbox

Mac 安装包下载地址:https://pan.baidu.com/s/1SYjVX2Dhz6TTbaif1Bk8RA 密码:64oo

拉取项目和子模块

1
2
3
git clone https://xxx.git
git submodule init
git submodule update

打包命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
环境安装
npm install

# Linux打包成AppImage文件
# 在Linux环境上执行
node_modules/.bin/electron-builder -l AppImage

# Windows打包成exe安装文件
# 在Windows环境下执行
node_modules/.bin/electron-builder -w nsis
node_modules/.bin/electron-builder -w --ia32 nsis

# 如果在非Windows上打包win程序，也可以借助docker 如下
# docker run --rm -it -v ${PWD}:/project electronuserland/builder:wine sh -c "node_modules/.bin/electron-builder -w nsis"

# Mac打包成dmg文件
# 在Mac环境下执行
node_modules/.bin/electron-builder -m dmg

打包参考链接

https://qii404.me/2019/07/10/electron.html

发表于

设计原则

如果把设计模式理解为优秀软件系统模块设计的最小抽象，那么设计原则就是这些抽象的指导思想。目的是设计一个易于扩展和维护的系统。设计模式的六大原则有：

  • Single Responsibility Principle：单一职责原则
  • Open Closed Principle：开闭原则
  • Liskov Substitution Principle：里氏替换原则
  • Law of Demeter：迪米特法则
  • Interface Segregation Principle：接口隔离原则
  • Dependence Inversion Principle：依赖倒置原则

单一职责原则

应该有且只有一个原因引起类的变化，一个类只负责一个职责。一个功能应该要划分成多少个职责类去实现，并没有明显的限定。举例说明对于用户管理，用户信息管理和用户行为管理可以做初步拆分，用户信息管理又可以拆分成普通信息维护和敏感信息的维护。又比如用户发生一笔支付行为可以初步拆分为交易信息管理和支付信息管理。职责划分的粗细的影响因素有对于业务理解程度、项目开发阶段等，过粗会造成一个处理类包含太多职责，过细又会增加开发维护成本。单一职责是“高内聚低耦合”设计的一种实现形式，单一职责即为同一职责内部的内聚性，降低不同职责之间的耦合性。

里氏替换原则

描述继承关系，子类全部实现或继承父类方法，子类可以扩展父类方法实现，将子类替换父类不会产生异常。在重构角度来说如果多个子类拥有相同的行为，可以将相同行为提取到父类实现，子类调用扩展父类实现。在开发上基于“组合大于继承”的原则，通过定义实现接口的形成被其它类调用。违反这个原则不一定会产生严重后果，但是会对后面的开发维护造成困难。

开闭原则

描述的是对于需求产生变化后，软件实体部分应该进行扩展开发，避免修改。通过扩展实体行为来响应需求变化，而不是通过修改现有软件代码。

迪米特法则

描述的是一个对象应该进行减少对于其它对象的理解。通过封装我们可以屏蔽类内部逻辑，只提供足够用且少量的方法来给外部使用，降低对象之间的耦合性。当一个接口或者一个对象被公开，意味着后面我们进行开发和维护的时候很难再将这个对象收回，重构内部逻辑时也会更加困难。

接口隔离原则

描述的是建立单一的接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量行为统一，避免臃肿。对于支付接口来说，定义类通用支付方法，对于获取分期支付信息也属于支付行为的一个环节，但不是所有实体类必须要实现的，可以拆分出来。

依赖倒置原则

描述的是实现类之间不能直接发生依赖关系，其依赖关系是通过接口或者抽象类产生，即面向接口编程。实现类依赖接口或者抽象类，而接口或者抽象类不依赖实现类。

设计模式

https://design-patterns.readthedocs.io/zh_CN/latest/index.html

发表于

一些小的点

  1. 坚持阅读英文技术资料，并至少翻译12篇技术文章。x
  2. 戒掉熬夜的坏习惯，习惯性去健身，保持精力的充沛。60%
  3. 刻意提高专注力，并坚持系统性的做技术储备。80%
  4. 常出去走走，看看外面的世界，准备至少两次的远途旅行。100%
  5. 找到一个互相合适的伴侣。100%
  6. 趁年轻努力挣钱，但是不要透支身体。50%
  7. 好好学说话，做一个有趣的人。60%

主要方向

  1. 英语学习，坚持阅读英文技术资料，至少翻译12篇技术文章，基本的口语表达。x
  2. 沟通能力，说话前多思考，减少小动作的出现，改变不好的下意识动作和反应。50%
  3. 正确锻炼，学会并养成跑步习惯，无氧健身增加身体健壮。90%

发音练习

《张浩翔 魅力声音必修课》
预计学习时间 2 天，整理笔记，刻意练习。注意学习的几个阶段。

做到了哪些

  1. 考了救护员证
  2. 去了天津、昆明、大理、丹东
  3. 跑了马拉松
  4. 去山顶露营

第一个半马

云南之旅

丹东之旅

救护员证

发表于
  • 六本本职技术书籍/专题
    • effective java done 01.29
    • Java 并发编程实战 done 02.14
    • 深入理解 Java 虚拟机 part 04.01
    • Java 性能优化 21 讲 done 12.01
  • 六本技术扩展书籍/专题
    • 图解密码技术 第三版 done 10.08
    • Linux 内核设计与实现（原书第三版）
    • 现代编译原理
    • 数据密集型应用系统设计
    • MySQL 实战 45 讲 part 08.26
    • Wireshark 数据包分析实战（第 3 版） done 2020.12.13
    • 实现领域驱动设计 part
  • 六本人文社科书籍
    • 精进 done 02.11
    • 我的改变：个人现代化 40 年 done 09.27
    • 高效 PDCA 工作术 done 09.16
    • 薄世宁医学通识讲义 done 10.20
    • 这里是中国 done 10.05
    • 活着 余华 done 12.10
    • 论中国 基辛格 done
    • 美国陷阱 done
  • 整理输出两篇高质量博客文章