有趣的技术

原文链接：How to profile JVM applications

Hi 大家好。工具团队（tooling team）近期的一个关注点是改进 sbt 贡献流程（ improvement of the contribution process to sbt）。我们一直在思考的另一个事情是 sbt 的性能。为一举解决这两件事情，我调研了 Jason Zaugg、Johannes Rudolph 这些人如何剖析 JVM 应用，这篇文章即是调研结果。

这里论述的技术应该可以应用于Java 和 Scala，也基本与你使用的工具无关。

火焰图（使用 async-profiler 生成）

剖析 JVM 应用的方式有多种，但新晋热门是Netflix 高级性能架构师（Senior Performance Architect …

原文：Query Parser Syntax

概览

Lucene 除了提供 API 方便开发者创建查询请求，还通过一个查询解析器（一个词法分析器，使用 JavaCC 将一个字符串翻译成一个 Lucene 查询）提供一种功能丰富的查询语言。

一般来说，查询解析器支持的语法在不同发布版本之间可能会有变化。当前这个文档页面描述的是当前这个发布版本的语法。如果你正在使用一个不同版本的 Lucene，请参考该版本自带的 docs/queryparsersyntax.html 文档。

在选择使用这个查询解析器之前，请考虑以下 3 点：

1. 如果你准备以编程的方式生成一个查询字符串，然后使用查询解析器来解析它。那么，你应该认真考虑一下是否应该直接使用查询 API 来构建查询。换句话说，查询解析器专门用于人类输入的文本，而不是程序生成的文本。
2. 不可分词（untokenized）的域（译者注：抱歉，此处没太理解）最好直接添加到查询中，而不是通过查询解析器来解析。如果一个域的值是通过应用自动生成的，那么应该为这个域自动生成查询子句 …

原文：Reactor 3 Reference Guide

1. 起步

1.1 Reactor 简介

Reactor 是为 JVM 准备的一个完全非阻塞的反应式编程基础组件，支持高效的需求管理（以管理“反压”的形式），直接与 Java 8 的函数式 API 集成，尤其是 CompletableFuture、Stream 以及 Duration，提供可组合的异步序列 API - Flux（适用于 N 个元素的序列）和 Mono（适用于 0 或 1个元素的序列）--- 并且全面地（extensively）实现了 反应式流（Reative Streams） 规范。

借助 …

原文：Java System.getProperty vs System.getenv

1、简介

Java 应用代码中会自动引入 java.lang 包。这个包包含很多常用的类，包括 NullPointerException、Object、Math、String 等等。

其中 java.lang.System 类是一个 final 类，这意味着开发者无法继承它，其所有方法都是静态的（static）。

System 类中有两个方法，分别来读取系统属性（system properties）和环境变量（environment variables），下面我们来看看这两者的区别。

2、使用 System.getProperty()

Java 平台使用一个 Properties 对象来提供本地系统相关的信息和配置 …

从毕业至今，在互联网行业从事软件研发工作，将近五年。这五年间，做过后端开发、前端开发、大数据处理等，使用过的编程语言包括：Python、PHP、Go、Java、JavaScript 等。

虽说编程语言各异，但我使用它们来写各种项目的代码却一直坚持两点：代码可读性和自解释性/自文档性（self-documentation）。这很大程度上应该是受到 Python 语言设计哲学的影响 - 追求简单易读易懂的代码。

很多人可能会认为这两点其实是一点 - 代码可读性，但我想做点区分：代码可读性突出对代码阅读者视觉上的影响，是否存在不必要的理解干扰，比如：必要的空行、变量定义与使用之间的距离、函数体/逻辑分支是否过长、逻辑表达是否直观等等。可读性高的代码通常都非常漂亮、赏心悦目。自解释性代码则更突出语义层面，比如：变量名称/函数名称/类名是否恰当、函数/方法/API 是否单一职责、工程目录结构/包/模块拆分是否符合“高内聚低耦合”原则等等 …

在我读大学那几年，设计模式可谓火极一时，各大公司校招面试也几乎都会考设计模式，反观现在，则似乎很少有人聊设计模式的话题。是因为设计模式过时了吗？还是只是一个错误的概念？从个人这几年的开发经验来看，答案是否定的，设计模式并未过时，更不是一个错误的概念。从曾经的“红极一时”到如今的“门可罗雀”，只是说明软件开发行业以更加客观理性的态度来看待设计模式。软件开发领域的技术概念也似乎总是遵循这样的流行度变迁，最终一次又一次地证明不存在“银弹”。

正确看待设计模式的前提是明白什么是设计模式。正如本书一开始就强调的：“设计模式的本质是在已有的方案之上发现更好的方案（而不是全新发明）”，这是一种务实的态度，设计模式并非是一种高大上或者神秘的东西，而是一些常见的软件工程设计问题的最佳实践方案。

那么应该如何学习设计模式？个人认为软件开发技术的学习都应该以实践为前提，只有理解实践过程中遇到的种种问题，才能明白那些技术的本质和目的是什么，每种新技术都是因某个/某些问题而出现的，软件开发高手一般都反对新手一开始就一股脑地学习设计模式。有些新手学了点设计模式的理论后，甚至在软件开发过程中生搬硬套，结果是适得其反。因此，软件开发人员应该在积累了一定的开发经验，再系统地学习设计模式，效果往往也能事半功倍。

现在有些积累一定开发经验的软件开发人员，在谈起设计模式时，一脸鄙夷。我想这也不是一种客观务实的态度。软件开发不是简单的累积代码，在实现业务功能的同时应该仔细考虑如何控制软件的复杂度。软件的复杂度分为两个层面：业务逻辑复杂度和代码实现复杂度。对同一个业务系统，不同的软件开发人员会有不同的实现 …

原文：Clarifications about Redis and Memcached

译者：youngsterxyf

译注：本文为Redis的作者所写

如果你了解我，就会知道我并不是那种认为竞品是一件坏事的人。实际上我喜欢用户有选择的空间，因此我很少做将Redis与其他技术做对比这类事情。

然而，为了选择正确的方案，用户必须获取正确的知识，这一点也是理所应当的。

本文的起因是读了Mike Perham写的一篇博文，你也许知道他是Sidekiq这一流行程序库的作者，Sidekiq又恰好使用Redis做后端。因此我毫不认为Mike是一个“反对”Redis的人。但在博文（你可以在 http://www.mikeperham.com/2015/09/24/storing-data-with-redis/ 找到这篇博文）中，他陈述到：要用缓存，“你可能应该选择Memcached（而不是Redis）”。这样看来，Mike确实简单地相信Redis不适合用做缓存，在文章中他是这样论述的：

• 1) Memcached专为缓存而设计
• 2) 它根本不会有磁盘I/O操作
• 3 …

原文：Parallelism in one line

译者：youngsterxyf

在并行处理能力方面，Python的声名并不太好。不考虑关于线程和GIL（多数情况下是合理的）的标准论据，我认为Python中关于并行的真正问题并不是一个技术问题，而是教学问题。围绕Python线程和多进程的常见教程，一般都写得不错，但也令人乏味 - 激烈非凡，对日常真正有用的东西却很少涉及。

沿袭的例子

在DuckDuckGo（DDG）中搜索“Python多线程教程”，简单调查一下排在前面的结果，就会发现它们给出的都是同样基于Class + Queue的示例。

介绍threading/multiprocessing、生产者/消费者的真实示例代码：

# coding: utf-8
# Example.py
'''
标准的多线程生产者/消费者模式
'''

import time 
import threading 
import Queue 

class Consumer(threading.Thread): 
  def __init__(self …