搜索[快速]结果-低调大师优秀个人博客

快速读懂对象存储 OSS数据处理介绍

云栖号快速入门：【点击查看更多云产品快速入门】不知道怎么入门？这里分分钟解决新手入门等基础问题，可快速完成产品配置操作！阿里云OSS为在云上的数据打通了一个处理与使用的快速通道。

2020-04-29

个人自主建站方式汇总（各种软件镜像快速建站）

Node.js（CentOS）手动部署 Node.js是一个基于Chrome V8引擎的JavaScript运行环境，用来方便、快速地搭建易于扩展的网络应用。

2020-04-03

Fhs-Framework 2.0.0 发布，轻量级快速开发平台

:https://gitee.com/fhs-opensource/fhs-framework/tree/v2.0.0 Fhs-Framework介绍： Fhs-Framework 是一款开箱即用的快速开发平台

2020-04-02

Flink 生态：一个案例快速上手 PyFlink

PyFlink 1.11 预览我们快速的预览一下即将与大家见面的 Flink 1.11 中的 PyFlink 的重点内容。

2020-03-18

JDK 14已经于2020年3月17日如期发布。本文介绍JDK 14特性。 JEP 305: instanceof的模式匹配（预览）通过对instanceof运算符进行模式匹配来增强Java编程语言。模式匹配允许程序中的通用逻辑，即从对象中有条件地提取组件，可以更简洁，更安全地表示。这是JDK 14中的预览语言功能。动机几乎每个程序都包含某种逻辑，这些逻辑结合了对表达式是否具有某种类型或结构的测试，然后有条件地提取其状态的组件以进行进一步处理。例如，以下是在Java程序中常见的instanceof-and-cast用法： if (obj instanceof String) { String s = (String) obj; // 使用s } 上述示例中，为了能够安全地将obj转为我们期望的String类型，需要通过instanceof运算符对obj进行类型判断。这里发生了三件事：测试obj是否是一个String 将obj转换为String 声明新的局部变量s，以便我们可以使用字符串值。这种模式很简单，并且所有Java程序员都可以理解，但是由于一些原因，它不是最优的。语法乏味同时执行类型检测和类型转换并不是必要的 String类型在程序中出现了3次，这混淆了后面更重要的逻辑重复的代码容易滋生错误在JDK 14中，上述代码可以改为下面的方式： if (obj instanceof String s) { // 使用s } 这样整个代码看上去更加简洁。描述类型测试模式由指定类型的谓词和单个绑定变量组成。在下面的代码中，短语String是类型测试模式： if (obj instanceof String s) { // 使用s } else { // 不能使用s } 如果obj是String的实例，则将其强制转换为String并分配给绑定变量s。绑定变量在if语句的true块中，而不在if语句的false块中。与局部变量的范围不同，绑定变量的范围由包含的表达式和语句的语义确定。例如，在此代码中： if (!(obj instanceof String s)) { .. s.contains(..) .. } else { .. s.contains(..) .. } true块中的s表示封闭类中的字段，false块中的s表示由instanceof运算符引入的绑定变量。当if语句的条件变得比单个instanceof更复杂时，绑定变量的范围也会相应地增长。例如，在此代码中： if (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..} 绑定变量s在&&运算符右侧以及true块中。仅当instanceof成功并分配给s时，才评估右侧。另一方面，在此代码中： if (obj instanceof String s || s.length() > 5) {.. s.contains(..) ..} 绑定变量s不在||右侧的范围内运算符，也不在true块的范围内。s指的是封闭类中的一个字段。 Joshua Bloch的经典著作Effective Java中有一段代码示例： @Override public boolean equals(Object o) { return (o instanceof CaseInsensitiveString) && ((CaseInsensitiveString) o).s.equalsIgnoreCase(s); } 这段代码可以使用新的语法写成： @Override public boolean equals(Object o) { return (o instanceof CaseInsensitiveString cis) && cis.s.equalsIgnoreCase(s); } 这个特性很有意思，因为它为更为通用的模式匹配打开了大门。模式匹配通过更为简便的语法基于一定的条件来抽取对象的组件，而instanceof刚好是这种情况，它先检查对象类型，然后再调用对象的方法或访问对象的字段。 JEP 343: 打包工具（孵化）该特性旨在创建一个用于打包独立Java应用程序的工具。动机许多Java应用程序需要以一流的方式安装在本机平台上，而不是简单地放置在类路径或模块路径上。对于应用程序开发人员来说，交付简单的JAR文件是不够的。他们必须提供适合本机平台的可安装软件包。这允许以用户熟悉的方式分发，安装和卸载Java应用程序。例如，在Windows上，用户希望能够双击一个软件包来安装他们的软件，然后使用控制面板删除该软件。在macOS上，用户希望能够双击DMG文件并将其应用程序拖到Application文件夹中。打包工具还可以帮助填补其他技术的空白，例如Java Web Start（已从JDK 11中删除）和pack200（已在JDK 11中弃用，可能在以后的版本中删除）。开发人员可以使用jlink将JDK分解为所需的最小模块集，然后使用打包工具生成一个压缩的、可安装的映像，该映像可以部署到目标计算机。为了以前满足这些要求，JDK 8分发了一个名为javapackager的打包工具。但是，作为删除JavaFX的一部分，该工具已从JDK 11中删除。描述 jpackage工具将Java应用程序打包到特定于平台的程序包中，该程序包包含所有必需的依赖项。该应用程序可以作为普通JAR文件的集合或作为模块的集合提供。受支持的特定于平台的软件包格式为： Linux：deb和rpm macOS：pkg和dmg Windows：MSI和EXE 默认情况下，jpackage会以最适合其运行系统的格式生成一个软件包。以下是基本用法： $ jpackage --name myapp --input lib --main-jar main.jar 用法 1. 基本用法：非模块化应用假设你有一个由JAR文件组成的应用程序，所有应用程序都位于lib目录下，并且主类在lib/main.jar中。下列命令 $ jpackage --name myapp --input lib --main-jar main.jar 将以本地系统的默认格式打包应用程序，并将生成的打包文件保留在当前目录中。如果main.jar中的MANIFEST.MF文件没有Main-Class属性，我们必须显式地指定主类： $ jpackage --name myapp --input lib --main-jar main.jar --main-class myapp.Main 打包的名称是myapp。要启动该应用程序，启动器将从输入目录复制的每个JAR文件都放在JVM的类路径上。如果希望生成默认格式以外的软件安装包，可以使用--type选项。例如要在macOS上生成pkg文件（而不是dmg文件），我们可以使用下面的命令： $ jpackage --name myapp --input lib --main-jar main.jar --type pkg 2. 基本用法：模块化应用如果你有一个模块化应用程序，该应用程序由lib目录中的模块化JAR文件和/或JMOD文件组成，并且主类位于myapp模块中，则下面的命令 $ jpackage --name myapp --module-path lib -m myapp 能够将其打包。如果myapp模块无法识别主类，则必须明确指定： $ jpackage --name myapp --module-path lib -m myapp/myapp.Main JEP 345: G1的NUMA内存分配优化通过实现可识别NUMA的内存分配，提高大型计算机上的G1性能。动机现代的多插槽计算机越来越多地具有非统一的内存访问（non-uniform memory access,NUMA），即内存与每个插槽或内核之间的距离并不相等。插槽之间的内存访问具有不同的性能特征，对更远的插槽的访问通常具有更大的延迟。并行收集器中通过启动-XX:+UseParallelGC能够感知NUMA，这个功能已经实现了多年了，这有助于提高跨多插槽运行单个JVM的配置的性能。其他HotSpot收集器没有此功能，这意味着他们无法利用这种垂直多路NUMA缩放功能。大型企业应用程序尤其倾向于在多个多插槽上以大堆配置运行，但是它们希望在单个JVM中运行具有可管理性优势。使用G1收集器的用户越来越多地遇到这种扩展瓶颈。描述 G1的堆组织为固定大小区域的集合。一个区域通常是一组物理页面，尽管使用大页面（通过 -XX:+UseLargePages）时，多个区域可能组成一个物理页面。如果指定了+XX:+UseNUMA选项，则在初始化JVM时，区域将平均分布在可用NUMA节点的总数上。在开始时固定每个区域的NUMA节点有些不灵活，但是可以通过以下增强来缓解。为了为mutator线程分配新的对象，G1可能需要分配一个新的区域。它将通过从NUMA节点中优先选择一个与当前线程绑定的空闲区域来执行此操作，以便将对象保留在新生代的同一NUMA节点上。如果在为变量分配区域的过程中，同一NUMA节点上没有空闲区域，则G1将触发垃圾回收。要评估的另一种想法是，从距离最近的NUMA节点开始，按距离顺序在其他NUMA节点中搜索自由区域。该特性不会尝试将对象保留在老年代的同一NUMA节点上。此分配政策中不包括Humongous区。对于这些区，将不做任何特别的事情。 JEP 349: JFR事件流公开JDK Flight Recorder数据以进行连续监视。动机 HotSpot VM通过JFR产生的数据点超过500个，但是使用者只能通过解析日志文件的方法使用它们。用户要想消费这些数据，必须开始一个记录并停止，将内容转储到磁盘上，然后解析记录文件。这对于应用程序分析非常有效，但是监控数据却十分不方便（例如显示动态更新数据的仪表盘）。与创建记录相关的开销包括：发出在创建新记录时必须发生的事件写入事件元数据（例如字段布局）写入检查点数据（例如堆栈跟踪）将数据从磁盘存储复制到单独的记录文件如果有一种方法，可以在不创建新记录文件的情况下，从磁盘存储库中读取正在记录的数据，就可以避免上述开销。描述 jdk.jfr模块里的jdk.jfr.consumer包，提供了异步订阅事件的功能。用户可以直接从磁盘存储库读取记录数据，也可以直接从磁盘存储流中读取数据，而无需转储记录文件。可以通过注册处理器（例如lambda函数）与流交互，从而对事件的到达进行响应。下面的例子打印CPU的总体使用率，并持有锁10毫秒。 try (var rs = new RecordingStream()) { rs.enable("jdk.CPULoad").withPeriod(Duration.ofSeconds(1)); rs.enable("jdk.JavaMonitorEnter").withThreshold(Duration.ofMillis(10)); rs.onEvent("jdk.CPULoad", event -> { System.out.println(event.getFloat("machineTotal")); }); rs.onEvent("jdk.JavaMonitorEnter", event -> { System.out.println(event.getClass("monitorClass")); }); rs.start(); } RecordingStream类实现了接口jdk.jfr.consumer.EventStream，该接口提供了一种统一的方式来过滤和使用事件，无论源是实时流还是磁盘上的文件。 public interface EventStream extends AutoCloseable { public static EventStream openRepository(); public static EventStream openRepository(Path directory); public static EventStream openFile(Path file); void setStartTime(Instant startTime); void setEndTime(Instant endTime); void setOrdered(boolean ordered); void setReuse(boolean reuse); void onEvent(Consumer<RecordedEvent> handler); void onEvent(String eventName, Consumer<RecordedEvent handler); void onFlush(Runnable handler); void onClose(Runnable handler); void onError(Runnable handler); void remove(Object handler); void start(); void startAsync(); void awaitTermination(); void awaitTermination(Duration duration); void close(); } 创建流的方法有3种: EventStream::openRepository(Path)从磁盘存储库中构造一个流。这是一种可以直接通过文件系统监视其他进程的方法。磁盘存储库的位置存储在系统属性jdk.jfr.repository中，可以使用API读取到。 EventStream::openRepository()方法执行进程内监控。与RecordingStream不同，它不会开始录制。相反，仅当通过外部方式（例如，使用JCMD或JMX）启动记录时，流才接收事件。 EventStream::openFile(Path)从记录文件中创建流，扩充了已经存在的RecordingFile类。该接口还可用于设置缓冲的数据量，以及是否应按时间顺序对事件进行排序。为了最大程度地降低分配压力，还可以选择控制是否应为每个事件分配新的事件对象，或者是否可以重用以前的对象。我们可以在当前线程中启动流，也可以异步启动流。 JVM每秒一次将线程本地缓冲区中存储的事件定期刷新到磁盘存储库。一个单独的线程解析最近的文件，直到写入数据为止，然后将事件推送给订阅者。为了保持较低的开销，仅从文件中读取活动订阅的事件。要在刷新完成后收到通知，可以使用EventStream::onFlush(Runnable)方法注册处理程序。这是在JVM准备下一组事件时将数据聚合或推送到外部系统的机会。 JEP 352: 非易失性映射字节缓冲区添加新的特定于JDK的文件映射模式，以便可以使用FileChannel API创建引用非易失性内存（non-volatile memory，NVM）的MappedByteBuffer实例。动机 NVM为应用程序程序员提供了在程序运行过程中创建和更新程序状态的机会，而减少了输出到持久性介质或从持久性介质输入时的成本。这对于事务程序特别重要，在事务程序中，需要定期保持不确定状态以启用崩溃恢复。现有的C库（例如Intel的libpmem）为C程序提供了对基层NVM的高效访问。他们还以此为基础来支持对各种持久性数据类型的简单管理。当前，由于频繁需要进行系统调用或JNI调用来调用原始操作，从而确保内存更改是持久的，因此即使仅使用Java中的基础库也很昂贵。同样的问题限制了高级库的使用，并且由于C中提供的持久数据类型分配在无法从Java直接访问的内存中这一事实而加剧了这一问题。与C或可以低成本链接到C库的语言相比，这使Java应用程序和中间件（例如Java事务管理器）处于严重的劣势。该特性试图通过允许映射到ByteBuffer的NVM的有效写回来解决第一个问题。由于Java可以直接访问ByteBuffer映射的内存，因此这可以通过实现与C语言中提供的客户端库等效的客户端库来解决第二个问题，以管理不同持久数据类型的存储。描述 1. 初步变更该JEP使用了Java SE API的两个增强功能：支持implementation-defined的映射模式 MppedByteBuffer::force方法以指定范围 2. 特定于JDK的API更改通过新模块中的公共API公开新的MapMode枚举值一个公共扩展枚举ExtendedMapMode将添加到jdk.nio.mapmode程序包： package jdk.nio.mapmode; . . . public class ExtendedMapMode { private ExtendedMapMode() { } public static final MapMode READ_ONLY_SYNC = . . . public static final MapMode READ_WRITE_SYNC = . . . } 在调用FileChannel::map方法创建映射到NVM设备文件上的只读或读写MappedByteBuffer时，可以使用上述的枚举值。如果这些标志在不支持NVM设备文件的平台上传递，程序会抛出UnsupportedOperationException异常。在受支持的平台上，仅当目标FileChannel实例是从通过NVM设备打开的派生文件时，才能传递这些参数。在任何其他情况下，都会抛出IOException异常。发布BufferPoolMXBean，用于跟踪MappedByteBuffer统计信息 JEP 358: 友好的空指针异常精确描述哪个变量为null，提高JVM生成的NullPointerException的可用性。动机每个Java开发人员都遇到过NullPointerException（NPE）问题。NPE几乎可以出现在程序的任意位置，因此尝试捕获和修复它们是不可能的。下面的代码： a.i = 99; JVM会打印出方法名、文件名和NPE异常的行数： Exception in thread "main" java.lang.NullPointerException at Prog.main(Prog.java:5) 使用这个错误报告，开发人员可以定位到a.i = 99;并推断对象a是null。但是对于更复杂的代码，不使用调试器就无法确定哪个变量为空。假设下面的代码中出现了一个NPE： a.b.c.i = 99; 仅仅使用文件名和行数，并不能精确定位到哪个变量为null，是a、b还是c？访问数组也会发生类似的问题。假设此代码中出现一个NPE： a[i][j][k] = 99; 文件名和行号不能精确指出哪个数组组件为空。是a还是a[i]或a[i][j]？一行代码可能包含多个访问路径，每个访问路径都可能是NPE的来源。假设此代码中出现一个NPE： a.i = b.j; 文件名和行号并不能确定哪个对象为空，是a还是b？ NPE也可能在方法调用中传递，看下面的代码： x().y().i = 99; 文件名和行号不能指出哪个方法调用返回null。是x()还是y()？描述 JVM在程序调用空引用的位置抛出NPE异常，通过分析程序的字节码指令，JVM可以精确判断哪个变量为空，并在NPE中描述详细信息（根据源代码）。包含方法名、文件名和行号的null-detail消息将显示在JVM的消息中。例如a.i = 99;的NPE异常可能是如下格式： Exception in thread "main" java.lang.NullPointerException: Cannot assign field "i" because "a" is null at Prog.main(Prog.java:5) 在更复杂的a.b.c.i = 99;语句中，NPE消息会包含导致空值的完整访问路径： Exception in thread "main" java.lang.NullPointerException: Cannot read field "c" because "a.b" is null at Prog.main(Prog.java:5) 同样，如果数组访问和赋值语句a[i][j][k] = 99;引发NPE： Exception in thread "main" java.lang.NullPointerException: Cannot load from object array because "a[i][j]" is null at Prog.main(Prog.java:5) 类似地，a.i = b.j;会引发NPE： Exception in thread "main" java.lang.NullPointerException: Cannot read field "j" because "b" is null at Prog.main(Prog.java:5) JEP 359: record（预览）通过record增强Java编程语言。record提供了一种紧凑的语法来声明类，这些类是浅层不可变数据的透明持有者。动机我们经常听到这样的抱怨：“Java太冗长”、“Java规则过多”。首当其冲的就是充当简单集合的“数据载体”的类。为了写一个数据类，开发人员必须编写许多低价值、重复且容易出错的代码：构造函数、访问器、equals()、hashCode()和toString()等等。尽管IDE可以帮助开发人员编写数据载体类的绝大多数编码，但是这些代码仍然冗长。从表面上看，将Record是为了简化模板编码而生的，但是它还有“远大”的目标：modeling data as data（将数据建模为数据）。record应该更简单、简洁、数据不可变。描述 record是Java的一种新的类型。同枚举一样，record也是对类的一种限制。record放弃了类通常享有的特性：将API和表示解耦。但是作为回报，record使数据类变得非常简洁。一个record具有名称和状态描述。状态描述声明了record的组成部分。例如： record Point(int x, int y) { } 因为record在语义上是数据的简单透明持有者，所以记录会自动获取很多标准成员：状态声明中的每个成员，都有一个 private final的字段；状态声明中的每个组件的公共读取访问方法，该方法和组件具有相同的名字；一个公共的构造函数，其签名与状态声明相同； equals和hashCode的实现； toString的实现。限制 records不能扩展任何类，并且不能声明私有字段以外的实例字段。声明的任何其他字段都必须是静态的。 records类都是隐含的final类，并且不能是抽象类。这些限制使得records的API仅由其状态描述定义，并且以后不能被其他类实现或继承。在record中额外声明变量也可以显式声明从状态描述自动派生的任何成员。可以在没有正式参数列表的情况下声明构造函数（这种情况下，假定与状态描述相同），并且在正常构造函数主体正常完成时调用隐式初始化（this.x=x）。这样就可以在显式构造函数中仅执行其参数的验证等逻辑，并省略字段的初始化，例如： record Range(int lo, int hi) { public Range { if (lo > hi) /* referring here to the implicit constructor parameters */ throw new IllegalArgumentException(String.format("(%d,%d)", lo, hi)); } } JEP 361: Switch Expressions （标准）扩展switch可以使其应用于语句或表达式。扩展switch使其可以用作语句或表达式，以便两种形式都可以使用传统的“case ... :”标签（带有贯穿）或“... ->”标签（不带有贯穿），还有另一个新语句，用于从switch表达式产生值。这些更改将简化日常编码，并为在交换机中使用模式匹配提供了方法。这些功能在JDK 12和JDK 13中是属于预览语言功能，在JDK 14中正式称为标准。动机当我们准备增强Java编程语言以支持模式匹配（JEP 305）时，现有switch语句的一些不规则性（长期以来一直困扰着用户）成为了障碍。下面的代码中，众多的break语句使代码变得冗长，这种“视觉噪声”通常掩盖了更多的错误。 switch (day) { case MONDAY: case FRIDAY: case SUNDAY: System.out.println(6); break; case TUESDAY: System.out.println(7); break; case THURSDAY: case SATURDAY: System.out.println(8); break; case WEDNESDAY: System.out.println(9); break; } 我们建议引入一种新形式的switch标签“case L ->”，以表示如果匹配标签，则只执行标签右边的代码。switch标签允许在每种情况下使用逗号分隔多个常量。现在可以这样编写以前的代码： switch (day) { case MONDAY, FRIDAY, SUNDAY -> System.out.println(6); case TUESDAY -> System.out.println(7); case THURSDAY, SATURDAY -> System.out.println(8); case WEDNESDAY -> System.out.println(9); } switch标签“case L ->”右侧的代码被限制为表达式、代码块或throw语句。这样局部变量的范围在本块之内，而传统的switch语句局部变量的作用域是整个模块！ switch (day) { case MONDAY: case TUESDAY: int temp = ... // The scope of 'temp' continues to the } break; case WEDNESDAY: case THURSDAY: int temp2 = ... // Can't call this variable 'temp' break; default: int temp3 = ... // Can't call this variable 'temp' } 许多现有的switch语句实质上是对switch表达式的模拟，其中每个分支要么分配给一个公共目标变量，要么返回一个值： int numLetters; switch (day) { case MONDAY: case FRIDAY: case SUNDAY: numLetters = 6; break; case TUESDAY: numLetters = 7; break; case THURSDAY: case SATURDAY: numLetters = 8; break; case WEDNESDAY: numLetters = 9; break; default: throw new IllegalStateException("Wat: " + day); } 上面的表述是复杂、重复且容易出错的。代码设计者的意图是为每天计算numLetters。这段代码可以改写成下面这段形式，更加清晰和安全： int numLetters = switch (day) { case MONDAY, FRIDAY, SUNDAY -> 6; case TUESDAY -> 7; case THURSDAY, SATURDAY -> 8; case WEDNESDAY -> 9; }; 描述 1. “case L ->”标签除了传统的“case L :”标签外，还定义了一种更简洁的形式：“case L ->”标签。如果表达式匹配了某个标签，则仅执行箭头右侧的表达式或语句；否则将不执行任何操作。 static void howMany(int k) { switch (k) { case 1 -> System.out.println("one"); case 2 -> System.out.println("two"); default -> System.out.println("many"); } } 下面的代码： howMany(1); howMany(2); howMany(3); 将会打印： one two many 2. Switch表达式 JDK 14扩展了switch语句，使其可以应用于表达式中。例如上述的howMany方法可以重写为如下形式： static void howMany(int k) { System.out.println( switch (k) { case 1 -> "one"; case 2 -> "two"; default -> "many"; } ); } 在通常情况下，switch表达式如下所示： T result = switch (arg) { case L1 -> e1; case L2 -> e2; default -> e3; }; 3. 通过yield产生值大多数switch表达式在“case L->”标签的右侧都有一个表达式。如果需要一个完整的块，JDK 14引入了一个新的yield语句来产生一个值，该值成为封闭的switch表达式的值。 int j = switch (day) { case MONDAY -> 0; case TUESDAY -> 1; default -> { int k = day.toString().length(); int result = f(k); yield result; } }; JEP 362: 弃用Solaris和SPARC端口不建议使用Solaris/SPARC，Solaris/x64和Linux/SPARC端口，以在将来的发行版中删除它们。动机放弃对这些端口的支持将使OpenJDK社区中的贡献者能够加速新功能的开发，这些新功能将推动平台向前发展。 JEP 363: 移除CMS垃圾收集器移除CMS（Concurrent Mark Sweep）垃圾收集器。动机在两年多以前的JEP 291中，就已经弃用了CMS收集器，并说明会在以后的发行版中删除，以加快其他垃圾收集器的发展。在这段时间里，我们看到了2个新的垃圾收集器ZGC和Shenandoah的诞生，同时对G1的进一步改进。G1自JDK 6开始便成为CMS的继任者。我们希望以后现有的收集器进一步减少对CMS的需求。描述此更改将禁用CMS的编译，删除源代码中gc/cms目录的内容，并删除仅与CMS有关的选项。尝试使用命令-XX:+UseConcMarkSweepGC开启CMS会收到以下警告： Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option UseConcMarkSweepGC; \ support was removed in <version> VM将使用默认收集器继续执行。 JEP 364: macOS系统上的ZGC（实验）将ZGC垃圾收集器移植到macOS。动机尽管我们希望需要ZGC可伸缩性的用户使用基于Linux的环境，但是在部署应用程序之前，开发人员通常会使用Mac进行本地开发和测试。还有一些用户希望运行桌面应用程序，例如带有ZGC的IDE。描述 ZGC的macOS实现由两部分组成：支持macOS上的多映射内存。 ZGC设计大量使用彩色指针，因此在macOS上我们需要一种将多个虚拟地址（在算法中包含不同颜色）映射到同一物理内存的方法。我们将为此使用mach microkernel mach_vm_remap API。堆的物理内存在单独的地址视图中维护，在概念上类似于文件描述符，但位于（主要是）连续的虚拟地址中。该内存被重新映射到内存的各种ZGC视图中，代表了算法的不同指针颜色。 ZGC支持不连续的内存保留。在Linux上，我们在初始化期间保留16TB的虚拟地址空间。我们假设没有共享库将映射到所需的地址空间。在默认的Linux配置上，这是一个安全的假设。但是在macOS上，ASLR机制会侵入我们的地址空间，因此ZGC必须允许堆保留不连续。假设VM实现使用单个连续的内存预留，则共享的VM代码也必须停止。如此一来，is_in_reserved()，reserved_region()和base()之类的GC API将从CollectedHeap中删除。 JEP 365: Windows系统上的ZGC（实验）将ZGC垃圾收集器移植到Windows系统上。描述 ZGC的大多数代码库都是平台无关的，不需要Windows特定的更改。现有的x64负载屏障支持与操作系统无关，也可以在Windows上使用。需要移植的特定于平台的代码与如何保留地址空间以及如何将物理内存映射到保留的地址空间有关。用于内存管理的Windows API与POSIX API不同，并且在某些方面不太灵活。 Windows实现的ZGC需要进行以下工作：支持多映射内存。 ZGC使用彩色指针需要支持堆多重映射，以便可以从进程地址空间中的多个不同位置访问同一物理内存。在Windows上，分页文件支持的内存为物理内存提供了一个标识（句柄），该标识与映射它的虚拟地址无关。使用此标识，ZGC可以将同一物理内存映射到多个位置。支持将分页文件支持的内存映射到保留的地址空间。 Windows内存管理API不如POSIX的mmap/munmap灵活，尤其是在将文件支持的内存映射到以前保留的地址空间区域中时。为此，ZGC将使用Windows概念的地址空间占位符。 Windows 10和Windows Server版本1803中引入了占位符概念。不会实现对Windows较早版本的ZGC支持。支持映射和取消映射堆的任意部分。 ZGC的堆布局与其动态调整堆页面大小（以及重新调整大小）相结合，需要支持映射和取消映射任意堆粒子。此要求与Windows地址空间占位符结合使用时，需要特别注意，因为占位符必须由程序显式拆分/合并，而不是由操作系统自动拆分/合并（如在Linux上）。支持提交和取消提交堆的任意部分。 ZGC可以在Java程序运行时动态地提交和取消提交物理内存。为了支持这些操作，物理内存将被划分为多个分页文件段并由其支持。每个分页文件段都对应一个ZGC堆粒度，并且可以独立于其他段进行提交和取消提交。 JEP 366: 弃用Parallel Scavenge和Serial Old垃圾收集算法的组合弃用Parallel Scavenge和Serial Old垃圾收集算法的组合。动机有一组GC算法的组合很少使用，但是维护起来却需要巨大的工作量：并行年轻代GC（ParallelScavenge）和串行老年代GC（SerialOld）的组合。用户必须使用-XX:+UseParallelGC -XX:-UseParallelOldGC来启用此组合。这种组合是畸形的，因为它将并行的年轻代GC算法和串行的老年代GC算法组合在一起使用。我们认为这种组合仅在年轻代很多、老年代很少时才有效果。在这种情况下，由于老年代的体积较小，因此完整的收集暂停时间是可以接受的。但是在生产环境中，这种方式是非常冒险的：年轻代的对象容易导致OutOfMemoryException。此组合的唯一优势是总内存使用量略低。我们认为，这种较小的内存占用优势（最多是Java堆大小的约3％）不足以超过维护此GC组合的成本。描述除了弃用选项组合-XX:+UseParallelGC -XX:-UseParallelOldGC外，我们还将弃用选项-XX:UseParallelOldGC，因为它唯一的用途是取消选择并行的旧版GC，从而启用串行旧版GC。因此，任何对UseParallelOldGC选项的明确使用都会显示弃用警告。 JEP 367: 移除Pack200工具和API 删除java.util.jar软件包中的pack200和unpack200工具以及Pack200 API。这些工具和API在Java SE 11中已经被注明为不推荐，并明确打算在将来的版本中删除它们。动机 Pack200是JSR 200在Java SE 5.0中引入的一种JAR文件压缩方案。其目标是“减少Java应用程序打包，传输和交付的磁盘和带宽需求”。开发人员使用一对工具pack200和unpack200压缩和解压缩其JAR文件。在java.util.jar包中提供了一个API。删除Pack200的三个原因：从历史上看，通过56k调制解调器缓慢下载JDK阻碍了Java的采用。 JDK功能的不断增长导致下载量膨胀，进一步阻碍了采用。使用Pack200压缩JDK是缓解此问题的一种方法。但是，时间已经过去了：下载速度得到了提高，并且JDK 9为Java运行时（JEP 220）和用于构建运行时的模块（JMOD）引入了新的压缩方案。因此，JDK 9和更高版本不依赖Pack200。 JDK 8是在构建时用pack200压缩的最新版本，在安装时用unpack200压缩的最新版本。总之，Pack200的主要使用者（JDK本身）不再需要它。除了JDK，Pack200还可以压缩客户端应用程序，尤其是applet。某些部署技术（例如Oracle的浏览器插件）会自动解压缩applet JAR。但是，客户端应用程序的格局已经改变，并且大多数浏览器都放弃了对插件的支持。因此，Pack200的主要消费者类别（在浏览器中运行的小程序）不再是将Pack200包含在JDK中的驱动程序。 Pack200是一项复杂而精致的技术。它的文件格式与类文件格式和JAR文件格式紧密相关，二者均以JSR 200所无法预料的方式发展。（例如，JEP 309向类文件格式添加了一种新的常量池条目，并且JEP 238在JAR文件格式中添加了版本控制元数据。）JDK中的实现是在Java和本机代码之间划分的，这使得维护变得很困难。 java.util.jar.Pack200中的API不利于Java SE平台的模块化，从而导致在Java SE 9中删除了其四种方法。总的来说，维护Pack200的成本是巨大的，并且超过了其收益。包括在Java SE和JDK中。描述 JDK最终针对的JDK功能发行版中将删除以前用@Deprecated(forRemoval = true)注解的java.base模块中的三种类型： java.util.jar.Pack200 java.util.jar.Pack200.Packer java.util.jar.Pack200.Unpacker 包含pack200和unpack200工具的jdk.pack模块先前已使用@Deprecated(forRemoval = true)进行了注解，并且还将在此JEP最终针对的JDK功能版本中将其删除。 JEP 368: Text Blocks（二次预览） Java语言增加文本块功能。文本块是多行字符串文字，能避免大多数转义。动机在Java中，HTML, XML, SQL, JSON等字符串对象都很难阅读和维护。 1. HTML 使用one-dimensional的字符串语法： String html = "<html>\n" + " <body>\n" + " <p>Hello, world</p>\n" + " </body>\n" + "</html>\n"; 使用two-dimensional文本块语法： String html = """ <html> <body> <p>Hello, world</p> </body> </html> """; 2. SQL 使用one-dimensional的字符串语法： String query = "SELECT `EMP_ID`, `LAST_NAME` FROM `EMPLOYEE_TB`\n" + "WHERE `CITY` = 'INDIANAPOLIS'\n" + "ORDER BY `EMP_ID`, `LAST_NAME`;\n"; 使用two-dimensional文本块语法： String query = """ SELECT `EMP_ID`, `LAST_NAME` FROM `EMPLOYEE_TB` WHERE `CITY` = 'INDIANAPOLIS' ORDER BY `EMP_ID`, `LAST_NAME`; """; 3. 多语言示例使用one-dimensional的字符串语法： ScriptEngine engine = new ScriptEngineManager().getEngineByName("js"); Object obj = engine.eval("function hello() {\n" + " print('\"Hello, world\"');\n" + "}\n" + "\n" + "hello();\n"); 使用two-dimensional文本块语法： ScriptEngine engine = new ScriptEngineManager().getEngineByName("js"); Object obj = engine.eval(""" function hello() { print('"Hello, world"'); } hello(); """); 描述文本块是Java语言的新语法，可以用来表示任何字符串，具有更高的表达能力和更少的复杂度。文本块的开头定界符是由三个双引号字符（"""）组成的序列，后面跟0个或多个空格，最后跟一个行终止符。内容从开头定界符的行终止符之后的第一个字符开始。结束定界符是三个双引号字符的序列。内容在结束定界符的第一个双引号之前的最后一个字符处结束。与字符串文字中的字符不同，文本块的内容中可以直接包含双引号字符。允许在文本块中使用\"，但不是必需的或不建议使用。与字符串文字中的字符不同，内容可以直接包含行终止符。允许在文本块中使用\n，但不是必需或不建议使用。例如，文本块： """ line 1 line 2 line 3 """ 等效于字符串文字： "line 1\nline 2\nline 3\n" 或字符串文字的串联： "line 1\n" + "line 2\n" + "line 3\n" JEP 370: 外部存储器API（孵化）引入一个API，以允许Java程序安全有效地访问Java堆之外的外部内存。动机许多Java的库都能访问外部存储，例如Ignite、mapDB、memcached及Netty的ByteBuf API。这样可以：避免垃圾回收相关成本和不可预测性跨多个进程共享内存通过将文件映射到内存中来序列化、反序列化内存内容。但是Java API却没有提供一个令人满意的访问外部内存的解决方案。 Java 1.4中引入的ByteBuffer API允许创建直接字节缓冲区，这些缓冲区是按堆外分配的，并允许用户直接从Java操作堆外内存。但是，直接缓冲区是有限的。开发人员可以从Java代码访问外部内存的另一种常见途径是使用sun.misc.Unsafe API。Unsafe有许多公开的内存访问操作（例如Unsafe::getInt和putInt）。使用Unsafe访问内存非常高效：所有内存访问操作都定义为JVM内在函数，因此JIT会定期优化内存访问操作。然而根据定义，Unsafe API是不安全的——它允许访问任何内存位置（例如，Unsafe::getInt需要很长的地址）。如果Java程序了访问某些已释放的内存位置，可能会使JVM崩溃。最重要的是，Unsafe API不是受支持的Java API，并且强烈建议不要使用它。虽然也可以使用JNI访问内存，但是与该解决方案相关的固有成本使其在实践中很少适用。整个开发流程很复杂，因为JNI要求开发人员编写和维护C代码段。 JNI本质上也很慢，因为每次访问都需要Java到native的转换。在访问外部内存时，开发人员面临一个难题：应该使用安全但受限（可能效率较低）的方法（例如ByteBuffer），还是应该放弃安全保证并接受不受支持和危险的Unsafe API？该JEP引入了受支持的，安全且有效的外部内存访问API。并且设计时就充分考虑了JIT优化。描述外部存储器访问API引入了三个主要的抽象：MemorySegment，MemoryAddress和MemoryLayout。 MemorySegment用于对具有给定空间和时间范围的连续内存区域进行建模。可以将MemoryAddress视为段内的偏移量，MemoryLayout是内存段内容的程序描述。可以从多种来源创建内存段，例如本机内存缓冲区，Java数组和字节缓冲区（直接或基于堆）。例如，可以如下创建本机内存段： try (MemorySegment segment = MemorySegment.allocateNative(100)) { ... } 上述代码将创建大小为100字节的，与本机内存缓冲区关联的内存段。内存段在空间上受限制；任何试图使用该段来访问这些界限之外的内存的尝试都会导致异常。正如使用try-with-resource构造所证明的那样，片段在时间上也是有界的。也就是说，它们已创建，使用并在不再使用时关闭。关闭段始终是一个显式操作，并且可能导致其他副作用，例如与该段关联的内存的重新分配。任何访问已关闭的内存段的尝试都将导致异常。空间和时间安全性检查对于确保内存访问API的安全性至关重要。通过获取内存访问var句柄可以取消引用与段关联的内存。这些特殊的var句柄具有至少一个强制访问坐标，类型为MemoryAddress，即发生取消引用的地址。它们是使用MemoryHandles类中的工厂方法获得的。要设置本机段的元素，我们可以使用如下所示的内存访问var句柄： VarHandle intHandle = MemoryHandles.varHandle(int.class); try (MemorySegment segment = MemorySegment.allocateNative(100)) { MemoryAddress base = segment.baseAddress(); for (int i = 0 ; i < 25 ; i++) { intHandle.set(base.offset(i * 4), i); } } 参考引用本文同步至: https://waylau.com/jdk-14-released/ https://openjdk.java.net/projects/jdk/14/

2020-03-18

如何快速找到“逃离”武汉的500万人？

我们暂且不论正常返乡过年和因封城惊慌“出逃”各有多少人，但从武汉出来的这500万人中，部分是携带病毒，那么如何快速找出这500万人呢？

2020-02-21

还在使用 SVN 的企业，如何快速迁移到 Gitee

前言 2000 年 CollabNet 创建了 Subversion 项目，一晃 SVN 已经诞生 20 年了，截至 r1873568 SVN 主分支共有 59674 次提交，32 个开发者，288 次发布，2005 年 Linus Torvalds 创建了 Git，截至 de93cc14ab7e8db7645d8dbe4fd2603f76d5851f，git 主分支共有 58209 次提交，1343 个贡献者，742 次发布，诸如 Google，Microsoft，Facebook 这样的巨无霸公司都在使用 Git，Git 主要开发者来自 Google 和 Microsoft。人多力量大，众人拾柴火焰高，有钱能使鬼推磨，贡献越多码越好，我们可以看到 SVN 只是缓慢变好，而 Git 却在飞速增强，到了今天为什么还不从 SVN 迁移到 Git？ Git 与 SVN 的比较 Git 是最流行的分布式版本控制系统，而 SVN 是集中式版本控制系统，顾名思义，SVN 的存储库将存储在中央服务器，而 Git 的存储库是存储在本地，当网络连接断开后，SVN 便无法进行提交，使用 Git 的开发者则可以先将代码提交到本地存储库，待网络恢复后再推送到远程服务器。特征 Git Subversion 分类分布式版本控制系统集中式版本控制系统许可协议 GPLv2 Apache 基金会 Software Freedom Conservancy Apache 交流会议 Git Merge 技术资讯 Git Rev News 分支轻量级分支（引用）复杂的分支模型，创建分支缓慢访问控制通常无细粒度权限控制目录级别的权限控制学习难度及其简单简单 Gitee 的功能用户在使用 SVN 时，通常感到舒适的功能有部分检出，目录权限控制等等，并一直以此为理由否定 Git 的进步，随着 Git 的不断增强，Gitee 开发者的不断努力，Gitee 逐渐拥有了这些功能。 2019 年 5 月底，Gitee 新增只读目录支持：SVN 的文件和目录只读特性，能否在 Git 也实现？并且，我写了一篇文章介绍如何实现 Git 目录权限控制。 2020 年 1 月 17 日，码云目前已经初步支持 Git 部分克隆，结合部分克隆和稀疏检出能够提供比 SVN 更好的部分检出体验。 Gitee 除了在 Git 功能上推陈出新，还在团队协作，企业管理上增加了很多功能，自定义权限管理更切合企业实际，任务，里程碑，成员周报能够让开发者异地完成诸多任务，并被考核。 2019 年度疫情爆发以来，各地交通管制，返程复工有诸多不便，使用 Gitee 远程工作正当其时，为什么还不从 SVN 迁移到 Gitee 呢？将 SVN 存储库迁移到 Gitee 企业只需要在 Gitee 上创建空存储库，然后将 SVN 存储库转换成 Git 存储库推送到 Gitee，便完成了向 Gitee 的迁移。使用 git svn 工具转换将 SVN 存储库转换成 Git 存储库非常简单，使用 git 自带的命令便可以完成： # convert repo to git repo gitsvnclonehttps://example.io/path/svn/repo-Ttrunk-bbranches-ttags gitremoteaddgitee git@gitee.com:example/name.git gitpush-ugitee--all 如果你以后无需追踪原有的 SVN 存储库，可以在 Push 之前运行： git branch -m trunk master 当存储库越来越大时，git svn 的缺陷便很明显了，转换耗时比较长，这也是 GCC 从 SVN 转成 Git 反反复复花了好几年的原因。使用 svn2git(ruby) 转换在 Github 上有个实用工具 svn2git，这个工具主要是简化了转换流程： sudo gem install svn2git svn2git http://svn.example.com/path/to/repo 这个工具能够提供更好的提交日志，唯一遗憾的是，自 2016 年以来便不在更新。使用 svn-all-fast-export/svn2git 转换 KDE 的开发者开发了 svn-all-fast-export/svn2git 这个工具在服务器上将 SVN 存储库转换成 git 存储库，由于省去网络传输和检出，速度要远胜于 git svn/svn2git(ruby)。 KDE 开发者撰写了使用示例：UsingSvn2Git，这一工具使用难度较高，需要创建规则文件，如果存储库较小，不建议使用此类工具。 create repository kdelibs match /trunk/KDE/kdelibs/ min revision 123453 max revision 456789 repository kdelibs branch master end match end repository 使用 git-svn-fast-import 转换 Gitee 还移植了一个 SVN to Git 的工具 git-svn-fast-import，这个转换又快又简单： $ mkdir -p repo.git && cd repo.git $ git init $ git-svn-fast-import --stdlayout -r 0:100000 /path/to/svnrepo progress Skipped revision 0 progress Imported revision 1 progress Imported revision 2 progress Imported revision 3 ... progress Imported revision 99999 progress Imported revision 100000 Gitee 开发者曾用此工具为某私有化客户将存储库从 SVN 转到 Git。简易 Git 命令指南 Git 任务说明命令配置用户名在创建提交时需要配置用户名 git config --global user.email 'name@email.io'; git config --global user.name 'Your Name' 初始化存储库 git init 克隆存储库本地存储库 git clone /path/to/local/repo SSH git clone git@gitee.com:example/example.git HTTPS git clone https://gitee.com/example/example.git 查看本地状态 git status 查看本地更改 git diff 添加修改比如新增或者增加了文件 A.txt git add A.txt 提交更改 git commit -m "Add a new file 'A.txt'" 推送到 Gitee git push 创建分支 git checkout -b NewBranchName 更多的命令可以访问 ProGit 或者运行 git help command 查看特定子命令的帮助信息。在 Gitee 上使用 SVN 功能随着开发者投入的逐步减少，因此使用 SVN 接入 Gitee 并不被提倡。但是，如果你仍然想要在迁移到 Gitee 后，使用落后的 SVN，你可以在项目设置页面打开 SVN，然后使用： svn co svn+ssh://gitee.com/example/repo 这将使用 SVN Over SSH 的方式访问远程存储库，只需要配置好 SSH 公钥，便可免密使用 SVN 协议访问远程 Git 存储库。更多的 Gitee SVN 可以访问：码云 SVN 支持总结开发者为开发者，Gitee 不断改进 Git 的体验，愿更多的企业从 SVN 迁移到 Gitee，享受更好的体验。

2020-02-06

Spring Cloud Stream 快速入门

本文内容翻译自官方文档，spring-cloud-stream docs，对 Spring Cloud Stream的应用入门介绍。一、Spring Cloud Stream 简介官方定义 Spring Cloud Stream 是一个构建消息驱动微服务的框架。 Spring Cloud Stream构建在SpringBoot之上，提供了Kafka，RabbitMQ等消息中间件的个性化配置，引入了发布订阅、消费组和分区的语义概念，有效的简化了上层研发人员对MQ使用的复杂度，让开发人员更多的精力投入到核心业务的处理。在实际开发过程中，服务与服务之间通信经常会使用到消息中间件，而以往使用了哪个中间件比如RabbitMQ，那么该中间件和系统的耦合性就会非常高，如果我们要替换为Kafka那么变动会比较大，使用Spring Cloud Stream来整合我们的消息中间件，可以降低系统和中间件的耦合性。二、Spring Cloud Stream 解决什么问题无感知的使用消息中间件 Stream解决了开发人员无感知的使用消息中间件的问题，因为Stream对消息中间件的进一步封装，可以做到代码层面对中间件的无感知。中间件和服务的高度解耦 Spring Cloud Stream进行了配置隔离，只需要调整配置，开发中可以动态的切换中间件(如rabbitmq切换为kafka)，使得微服务开发的高度解耦，服务可以关注更多自己的业务流程。关注公众号：架构进化论，获得第一手的技术资讯和原创文章三、核心概念和应用模型主要概念 Spring Cloud Stream 为各大消息中间件产品提供了个性化的自动化配置实现，引用了发布-订阅、消费组、分区的三个核心概念。 Spring Cloud Stream提供了很多抽象和基础组件来简化消息驱动型微服务应用。包含以下内容： Spring Cloud Stream的应用模型绑定抽象持久化发布／订阅支持消费者组支持分片支持（Partitioning Support）可插拔API 应用模型 Spring Cloud Stream由一个中立的中间件内核组成。Spring Cloud Stream会注入输入和输出的channels，应用程序通过这些channels与外界通信，而channels则是通过一个明确的中间件Binder与外部brokers连接。各大消息中间件的绑定抽象 Spring Cloud Stream提供对Kafka，Rabbit MQ，Redis，和Gemfire的Binder实现。Spring Cloud Stream还包括了一个TestSupportBinder，TestSupportBinder预留一个未更改的channel以便于直接地、可靠地和channels通信。集成Kafka <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-stream-binder-kafka</artifactId> </dependency> 集成RabbitMQ <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-stream-rabbit</artifactId> </dependency> 分区支持 Spring Cloud Stream支持在一个应用程序的多个实例之间数据分区，在分区的情况下，物理通信介质（例如，topic代理）被视为多分区结构。一个或多个生产者应用程序实例将数据发送给多个消费应用实例，并保证共同的特性的数据由相同的消费者实例处理。 Spring Cloud Stream提供了一个通用的抽象，用于统一方式进行分区处理，因此分区可以用于自带分区的代理（如kafka）或者不带分区的代理（如rabbiemq）分区在有状态处理中是一个很重要的概念，其重要性体现在性能和一致性上，要确保所有相关数据被一并处理，例如，在时间窗平均计算的例子中，给定传感器测量结果应该都由同一应用实例进行计算。四、编程模型 Spring Cloud Stream提供了一些预定义的注解，用于绑定输入和输出channels，以及如何监听channels。通过@EnableBinding触发绑定将@EnableBinding注解添加到应用的配置类，就可以把一个spring应用转换成Spring Cloud Stream应用，@EnableBinding注解本身就包含@Configuration注解，会触发Spring Cloud Stream 基本配置。 @Import(...) @Configuration @EnableIntegration public @interface EnableBinding { ... Class<?>[] value() default {}; } @Input 与 @Output 一个Spring Cloud Stream应用可以有任意数目的input和output通道，后者通过@Input和@Output注解在接口中定义。 @StreamListener 定义在方法中，被修饰的方法注册为消息中间件上数据流的事件监听器，注解中属性值对应了监听的消息通道名。 Source，Sink和Processor Spring Cloud Stream提供了三个开箱即用的预定义接口。Source用于有单个输出（outbound）通道的应用。 public interface Source { String OUTPUT = "output"; @Output(Source.OUTPUT) MessageChannel output(); } Sink用于有单个输入（inbound）通道的应用。 public interface Sink { String INPUT = "input"; @Input(Sink.INPUT) SubscribableChannel input(); } Processor用于单个应用同时包含输入和输出通道的情况。 public interface Processor extends Source, Sink { } 五、Stream极简实例下面是一个非常简单的 SpringBootApplication应用，通过依赖Spring Cloud Stream，从Input通道监听消息然后返回应答到Output通道，只要添加配置文件就可以应用。 @SpringBootApplication @EnableBinding(Processor.class) public class MyLoggerServiceApplication { public static void main(String[] args) { SpringApplication.run(MyLoggerServiceApplication.class, args); } @StreamListener(Processor.INPUT) @SendTo(Processor.OUTPUT) public LogMessage enrichLogMessage(LogMessage log) { return new LogMessage(String.format("[1]: %s", log.getMessage())); } } 下面解释下这个示例中相关注解的应用： @EnableBinding声明了这个应用程序绑定了2个通道：INPUT和OUTPUT。这2个通道是在接口Processor中定义的（Spring Cloud Stream默认设置）。所有通道都是配置在一个具体的消息中间件或绑定器中。@StreamListener(Processor.INPUT)表明这里在input中提取消息，并且处理。@SendTo(Processor.OUTPUT)表明在output中返回消息。总结这篇文章根据Spring Cloud Stream的官方文档，对Stream做了一个整体的介绍，包括设计目标，应用场景，业务模型以及对外开放的注解，后面我会通过一个实例，演示 Spring Cloud Stream 的应用。

2020-02-02

quickly 1.4 版本发布，快速前端切图css框架

www.qietu.com/quickly/v1.4/ 关于框架 quicklyCSS框架曾用名 ThinkCSS,QuickCSS ，是武汉切图网络技术有限公司（简称切图网）基于多年前端外包经验开发的一套快速响应式切图框架

2019-12-27

Linux CentOS环境下通过yum命令快速安装软件

为提升我们在云服务器上的软件安装效率，减少下载和安装软件的成本，在 CentOS 环境下，我们可以通过 yum 命令快速安装软件。对于 YUM 下载源，我们不需要添加软件源，可以直接安装软件包。

2019-12-10

阿里云数据库MySQL版快速入门指南

阿里云数据库MySQL版快速入门视频课程：阿里云大学—开发者课堂

2019-11-22

不加班的秘诀：如何通过AOE快速集成NCNN？

直接集成NCNN的缺点直接集成NCNN相对麻烦，为SqueezeNet接入NCNN，把相关的模型文件，NCNN的头文件和库，JNI调用，前处理和后处理相关业务逻辑等。把这些内容都放在SqueezeNet Sample工程里。这样简单直接的集成方法，问题也很明显，和业务耦合比较多，不具有通用性，前处理后处理都和SqueezeNcnn这个Sample有关，不能很方便地提供给其他业务组件使用。深入思考一下，如果我们把AI业务，作为一个一个单独的AI组件提供给业务的同学使用，会发生这样的情况：每个组件都要依赖和包含NCNN的库，而且每个组件的开发同学，都要去熟悉NCNN的接口，写C的调用代码，写JNI。所以我们很自然地会想到要提取一个NCNN的组件出来，提取以后如图所示： AOE SDK里的NCNN组件有了AOE SDK,就可以使操作更加简便。在AOE开源SDK里，我们提供了NCNN组件，下面我们从4个方面来讲一讲NCNN组件： 1.NCNN组件的设计2.对SqueezeNet Sample的改造3.应用如何接入NCNN组件4.对NCNN组件的一些思考 NCNN组件的设计 NCNN组件的设计理念是组件里不包含具体的业务逻辑，只包含对NCNN接口的封装和调用。具体的业务逻辑，由业务方在外部实现。在接口定义和设计上，我们参考了TF Lite的源码和接口设计。目前提供的对外调用接口，如下图： // 加载模型和param void loadModelAndParam(...) // 初始化是否成功 boolean isLoadModelSuccess() // 输入rgba数据 void inputRgba(...) // 进行推理 void run(...) // 多输入多输出推理 void runForMultipleInputsOutputs(...) // 得到推理结果 Tensor getOutputTensor(...) // 关闭和清理内存 void close() 而机智骚年本人，用的是这个： ├── AndroidManifest.xml ├── cpp │ └── ncnn │ ├── c_api_internal.h │ ├── include │ ├── interpreter.cpp │ ├── Interpreter.h │ ├── jni_util.cpp │ ├── jni_utils.h │ ├── nativeinterpreterwrapper_jni.cpp │ ├── nativeinterpreterwrapper_jni.h │ ├── tensor_jni.cpp │ └── tensor_jni.h ├── java │ └── com │ └── didi │ └── aoe │ └── runtime │ └── ncnn │ ├── Interpreter.java │ ├── NativeInterpreterWrapper.java │ └── Tensor.java └── jniLibs ├── arm64-v8a │ └── libncnn.a └── armeabi-v7a └── libncnn.a ●Interpreter，提供给外部调用，提供模型加载，推理这些方法。 ●NativeInterpreterWrapper是具体的实现类，里面对native进行调用。 ●Tensor，主要是一些数据和native层的交互。 AOE NCNN用的好，任务完成早，奥秘在此。 1.支持多输入多输出。 2.使用ByteBuffer来提升效率。 3.使用Object作为输入和输出（实际支持了Bytebuffer和多维数据组）光说不练假把式，AOE NCNN的实现过程，且听我细细道来。如何支持多输入多输出为了支持多输入和多输出，我们在Native层创建了一个Tensor对象的列表，每个Tensor对象里保存了相关的输入和输出数据。Native层的Tensor对象，通过tensor_jni提供给java层调用，java层维护这个指向native层tensor的“指针”地址。这样在有多输入和多输出的时候，只要拿到这个列表里的对应的Tensor，就可以就行数据的操作了。 ByteBuffer的使用 ByteBuffer，字节缓存区处理子节的，比传统的数组的效率要高。DirectByteBuffer，使用的是堆外内存，省去了数据到内核的拷贝，因此效率比用ByteBuffer要高。当然ByteBuffer的使用方法不是我们要说的重点，我们说说使用了ByteBuffer以后，给我们带来的好处： 1. 接口里的字节操作更加便捷，例如里面的putInt，getInt，putFloat，getFloat，flip等一系列接口，可以很方便的对数据进行操作。2. 和native层做交互，使用DirectByteBuffer，提升了效率。我们可以简单理解为java层和native层可以直接对一块“共享”内存进行操作，减少了中间的字节的拷贝过程。如何使用Object作为输入和输出目前我们只支持了ByteBuffer和MultiDimensionalArray。在实际的操作过程中，如果是ByteBuffer，我们会判断是否是direct buffer，来进行不同的读写操作。如果是MultiDimensionalArray，我们会根据不同的数据类型（例如int, float等），维度等，来对数据进行读写操作。对SqueezeNet Sample的改造集成AOE NCNN组件以后，让SqueezeNet依赖NCNN Module，SqueezeNet Sample里面只包含了模型文件，前处理和后处理相关的业务逻辑，前处理和后处理可以用java，也可以用c来实现，由具体的业务实现来决定。新的代码结构变得非常简洁，目录如下： ├── AndroidManifest.xml ├── assets │ └── squeeze │ ├── model.config │ ├── squeezenet_v1.1.bin │ ├── squeezenet_v1.1.id.h │ ├── squeezenet_v1.1.param.bin │ └── synset_words.txt └── java └── com └── didi └── aoe └── features └── squeeze └── SqueezeInterpreter.java ↑ Sample也适用于其他的AI业务组件对NCNN组件的调用。应用如何接入NCNN组件对NCNN组件的接入，有两种方式 ●直接接入 ●通过AOE SDK接入 ▲两种接入方式比较：不BATTLE了，我单方面宣布，AOE SDK完胜！对NCNN组件的总结和思考通过对NCNN组件的封装，现在业务集成NCNN更加快捷方便了。之前我们一个新的业务集成NCNN，可能需要半天到一天的时间。使用AOE NCNN组件以后，可能只需要1-2小时的时间。当然NCNN组件目前还存在很多不完善的地方，我们对NCNN还需要去加深学习和理解。后面会通过不断的学习，持续的对NCNN组件进行改造和优化。 - - - - - - - - - - - - - - - - - - - - - - - - - - - - A o E - - - - - - - - - - - - - - - - - - - - - - - - - - - -

2019-11-20

CakePHP 4.0.0 RC1 发布，PHP 快速开发框架

CakePHP 4.0.0 的第一个候选版本发布了，更新内容如下：新的route _path 格式已添加至Router::url() http 和控制台库已创建独立程序包开发错误页面会在异常消息中保留内联代码高亮和换行符已弃用 SecurityComponent，并由 FormProtectionComponent 代替 ConsoleErrorHandler 已移至 Error 包 Validation::time()现在接受微秒为 PHP>7.3.0 添加了 SameSite cookie 支持增加了用于 char，datetimefractional 和 timestampfractional 的新数据库类型新增InstanceConfigTrait::getConfigOrFail() 新的 isLinkedTo 和 isNotLinkedTo 规则已添加到ORM\RulesChecker Date 和 FrozenDate 对象现在使用默认时区而不是 UTC 重构了 Controller action dispatching，使将来添加 DI 容器变得更加容易 Routing前缀现在是 PascalCased 而不是 under_scored 详情见更新说明： https://bakery.cakephp.org/2019/11/15/cakephp_400RC1_released.html

2019-11-19

如何快速定位Android端GPU问题之工具介绍

GAPID GAPID是Google下的一个开源库，可用于记录发送给GPU的API调用及渲染状态检查，目前主要用于Android端，对OpenGL ES及Vulkan的支持最完善，使用此工具可以协助定位排查端上OpenGL ES的渲染效果、渲染状态及错误、渲染绑定的shader等资源，同时可以即时修改渲染每步中的变量值并查看新的渲染效果。下载安装下载地址：https://github.com/google/gapid/releases当前最新的稳定版本是1.6.1，也可以下载开发版1.7.0，注意开发版本更新比较频繁，也可能会出现运行过程中崩溃问题，建议使用稳定版本。下载后默认安装即可。环境配置启动界面如下图选择Capture a new trace，如下图我的机器上的默认设置注意：如果第一行Device无法显示，可以点击右侧图标刷

2019-11-01

如何通过火焰图快速定位Cassandra性能瓶颈

运维大规模分布式系统的比较重要的一个挑战是可以有能力指出关键问题所在。在没有证据支持某种说法的情况下，当故障出现时，总是责怪组件（通常是数据库）的偶然性问题是很常见的一件事。我们已经讨论过监控工具、图形化输出、以及报警metric的重要性，并使用分布式tracing系统（比如zikin）去正确的辨别复杂系统的根源问题。一旦你把问题缩小到一个单一的系统上面，你会怎么做？通常我们都会说这个会具体问题具体对待。有的问题是临时的，比如坏盘。有的问题却涉及到人为引入的变化，比如部署或者是错误的配置。这些都是有直接简单的解决办法：换盘或者是回滚部署。但是如果出现的问题超出简单变化的范畴，那怎么办？到现在为止还没有提到的是规模增长造成的问题。规模可以成为另一个困难的问题，因为复现这个问题一般情况下是很微妙且复杂的。这些挑战有时是通过吞吐量（每秒

2019-10-25

Jboot 2.2.2 发布，分布式开发更加简单快速

Jboot 是一个基于 JFinal、JFinal-Undertow、Dubbo 等开发的微服务框架，帮助开发者降低微服务开发门槛。同时完美支持在 idea、eclipse 下多 maven 模块，对java代码、html、css、js 等资源文件进行热加载，爽爽的开发。 Jboot v2.2.2 更新内容如下：新增：新增 AopCache 工具类，方便直接操作 AOP 缓存新增：Model 新增 findListByIds() 方法，用于更加多个ID查询多个Model 新增：CacheUtil 新增 use() 方法，方便通过 CacheUtil 对不同的缓存进行操作优化：重构 Cache AOP 拦截器的包结构，使之更加合理优化：优化 Cache 的相关工具类，删除多余的无用代码优化：添加 Columns.EMPTY 变量，用于查询时在某些情况无需创建变量优化：find 系列方法更好的答应 debug sql，同时删除 JbootModel 无需重写的某些方法 maven 依赖： <dependency> <groupId>io.jboot</groupId> <artifactId>jboot</artifactId> <version>2.2.2</version> </dependency> Hello World： @RequestMapping("/") public class HelloworldController extends JbootController { public void index(){ renderText("hello world"); } public static void main(String[] args){ JbootApplication.run(args); } }

2019-10-07

Jboot 2.2.1 发布，分布式开发更加简单快速

Jboot 是一个基于 JFinal、JFinal-Undertow、Dubbo 等开发的微服务框架，帮助开发者降低微服务开发门槛。同时完美支持在 idea、eclipse 下多 maven 模块，对java代码、html、css、js 等资源文件进行热加载，爽爽的开发。 Jboot v2.2.1 更新内容如下：优化：findCountByColumns 返回的类型由 Long 改为 long，客户端调用的时候不需要再判断是否为null。优化：JbootDbManager 重命名为 ArpManager 新增：JbootDb 工具类，用于增强 JFinal 的Db 工具类，增加 JbootDb.findByColumns 及其 JbootDb.deleteByColumns 系列方法 maven 依赖： <dependency> <groupId>io.jboot</groupId> <artifactId>jboot</artifactId> <version>2.2.1</version> </dependency> Hello World： @RequestMapping("/") public class HelloworldController extends JbootController { public void index(){ renderText("hello world"); } public static void main(String[] args){ JbootApplication.run(args); } }

2019-10-04

Jboot 2.2.0 发布，分布式开发更加简单快速

Jboot 是一个基于 JFinal、JFinal-Undertow、Dubbo 等开发的微服务框架，帮助开发者降低微服务开发门槛。同时完美支持在 idea、eclipse 下多 maven 模块，对java代码、html、css、js 等资源文件进行热加载，爽爽的开发。明天 10.1 了，今天发布 2.2.0 给大家一个国企的礼物。这个版本主要是新增了根据Columns进行增删改查的方法，同时增强了代码生成器的生成能力，Jboot 历时近3年，已经发布了 100+ 个版本，成熟而稳定。 Jboot 3.0 也在开始计划了，预计年底能出来第一个版本。 Jboot v2.2.0 更新内容如下：新增：JbootModel 新增 deleteByColumns 的方法新增：JbootModel 新增 batchDeleteByIds 的方法新增：JbootModel 新增 findCountByColumns 的方法新增：Columns 查询新增 not in 的功能新增：代码生成器新增 findFirstByColumns 系列方法新增：代码生成器新增 findListByColumns 系列方法新增：代码生成器新增 findCountByColumns 系列方法新增：代码生成器新增 paginateByColumns 系列方法新增：代码生成器新增 deleteByColumns 系列方法优化：优化Service层的代码生成器优化：AnnotationUtil 的性能问题优化：更新 jboot/cglib/fastjson/druid/HikariCP 等依赖优化：完善 docker 部署的相关问题优化：优化 DialectKit 的方法逻辑，使之更加容易阅读修复：修复 fatjar 打包时，获取classpath 和 banner等不正确的问题修复： JbootScheduleManager 无法移除已经添加的任务的问题 maven 依赖： <dependency> <groupId>io.jboot</groupId> <artifactId>jboot</artifactId> <version>2.2.0</version> </dependency> Hello World： @RequestMapping("/") public class HelloworldController extends JbootController { public void index(){ renderText("hello world"); } public static void main(String[] args){ JbootApplication.run(args); } }

2019-09-30

运维编排系列场景-----快速生成模版shell命令

应用场景当通过模版的方式在一台机器上运行shell文件时，需要在模版中把当前的所有shell命令都需要手动操作写进模版中，并添加需要写入的shell文件，尤其是遇到一些需要转译的特殊字符时，还需要手改，操作较为浪费时间。解决方案把当前需要修改的shell命令写入一个本地shell文件，通过python脚本的方式来实现把此文件内的所有命令转化为某一种特定的形式，及解决转化后的脚本特殊字符写进模版中转译的问题，转化的脚本可以直接输入到模版中运行，并保留格式。一、转化shell脚本下面为用python实现的转化脚本，并将脚本命名为：oos_convert import re import sys commands = sys.argv # 要翻译的shell 脚本 file_path = '' or commands[1] def translate(): with open(file_path, 'r+', encoding='utf-8') as f: lines = f.readlines() for index, line in enumerate(lines): if index == 0: continue # print() new_line = repr(line).replace('\\t', ' ').replace('\\n', '').strip("'") if new_line.startswith('"'): print(new_line + ',') else: rep_line = new_line.replace('"', '\\"') print('"' + rep_line + '",') translate() Python脚本的运行方式：运行命令：pythonoos_convert.pyxxx.sh (例如：pythonoos_convert.py~/command.sh）或者在pycharm等编辑工具中直接运行，在编辑工具中需要将file_path根据实际需求来补充。如下所示为一个shell文件内的命令将以上python代码写入到一个自定义命名的py的文件中，在命令行中用python运行此文件，其运行结果如下所示，并将运行出来的结果复制到JSON格式的模版中。二、打开控制台，找到运维编排三、创建模版按如下所示编辑模版，并将python脚本转化的内容，复制到下面的模版中。注意：此脚本转化的内容仅支持JSON格式。 { "FormatVersion": "OOS-2019-06-01", "Description": "Creates a cloud assistant command and triggers it on one ECS instance.", "Parameters": { "instanceId": { "Description": "The ID of ECS instance that will invoke command.", "Type": "String", "AllowedPattern": "i-[A-Za-z0-9]*", "MinLength": 1, "MaxLength": 30 }, "regionId": { "Type": "String" }, "OOSAssumeRole": { "Description": "The RAM role to be assumed by OOS.", "Type": "String", "Default": "OOSServiceRole" } }, "RamRole": "{{ OOSAssumeRole }}", "Tasks": [ { "Name": "createCommand", "Action": "ACS::ExecuteAPI", "Description": "Creates a cloud assistant command.", "Properties": { "Service": "ECS", "API": "CreateCommand", "Parameters": { "CommandContent": { "Fn::Base64Encode": { "Fn::Join": [ "\n", [ "echo hello world", "echo hello world", "", "echo \\$hello,this is aliyun", "echo $hello,this is aliyun", "", "if [[ \"a\" == \"a\" ]]; then", " echo hello", "else", " echo word", "fi", "", "echo 'hi judy'" ] ] } }, "RegionId": "{{ regionId }}", "Name": "{{ ACS::ExecutionId }}", "Type": "RunShellScript", "WorkingDir": "/root", "Timeout": 30 } }, "Outputs": { "CommandId": { "Type": "String", "ValueSelector": "CommandId" } } }, { "Name": "invokeCommand", "Action": "ACS::ExecuteAPI", "Description": "Triggers a cloud assistant command on one ECS instances.", "Properties": { "Service": "ECS", "API": "InvokeCommand", "Parameters": { "CommandId": "{{ createCommand.CommandId }}", "InstanceIds": [ "{{ instanceId }}" ], "RegionId": "{{regionId}}" } }, "Outputs": { "InvokeId": { "Type": "String", "ValueSelector": "InvokeId" } } }, { "Name": "untilInvocationReady", "Action": "ACS::WaitFor", "Description": "Waits for the command to be completed.", "Delay": 20, "Retries": 30, "DelayType": "Constant", "Properties": { "Service": "ECS", "API": "DescribeInvocations", "Parameters": { "RegionId": "{{regionId}}", "InvokeId": "{{ invokeCommand.InvokeId }}" }, "DesiredValues": [ "Finished" ], "StopRetryValues": [ "Failed" ], "PropertySelector": "Invocations.Invocation[].InvokeStatus" }, "OnError": "deleteCommand" }, { "Name": "describeInvocationResults", "Action": "ACS::ExecuteAPI", "Description": "Views the command output of a cloud assistant command in the specified ECS instance.", "Properties": { "Service": "ECS", "API": "DescribeInvocationResults", "Parameters": { "RegionId": "{{regionId}}", "InvokeId": "{{ invokeCommand.InvokeId }}" } }, "Outputs": { "InvocationResult": { "Type": "String", "ValueSelector": "Invocation.InvocationResults.InvocationResult[].Output" } } }, { "Name": "checkInvocationResult", "Action": "ACS::CheckFor", "Description": "Views the command output of a cloud assistant command in the specified ECS instance.", "Properties": { "Service": "ECS", "API": "DescribeInvocationResults", "Parameters": { "RegionId": "{{regionId}}", "InvokeId": "{{ invokeCommand.InvokeId }}" }, "PropertySelector": "Invocation.InvocationResults.InvocationResult[].ExitCode", "DesiredValues": [ 0 ] } }, { "Name": "deleteCommand", "Action": "ACS::ExecuteAPI", "Description": "Deletes a cloud assistant command.", "Properties": { "Service": "ECS", "API": "DeleteCommand", "Parameters": { "RegionId": "{{ regionId}}", "CommandId": "{{ createCommand.CommandId }}" } } } ], "Outputs": { "InvocationOutput": { "Type": "String", "Value": { "Fn::Base64Decode": "{{ describeInvocationResults.InvocationResult }}" } } } } 四、校验模版，并格式化模版脚本转化完的模版格式如下所示，转化的脚本，如果格式没有对齐，点击鼠标右键，选择Format Doucument，来使模版格式化。注意：需要手动删除脚本最后一句的逗号。五、创建执行找到创建好的模版，点击创建执行六、点击创建执行模版开始正式执行，在输入的实例上执行想要运行的shell命令。总结由以上举例可见，此脚本的作用为手动操作节省了时间，并把在模版中解决了特殊字符转译的问题。此脚本还有很多不完善的地方，欢迎提出意见。欢迎使用OOS OOS客户支持钉钉群：23330931OOS管理控制台的链接OOS帮助文档的链接

2019-09-06

OSChina 周二乱弹 —— 公交转地铁快速通道

“公交转地铁快速通道，李奥纳多、拉斐尔、多纳泰罗和米开朗琪罗到站了。”

2019-09-03

精选列表