Fireworks和Gravit

2013年5月6日,Adobe宣布停止发布Fireworks的新版本,Fireworks的版本号就此永远停留在了CS6。实际上,与每次更新都带来很多令人惊呼黑科技的PS相比,Fireworks的进化在CS6之前就已经停止了。尽管CS6现在仍可使用,但未来会如何,无人知晓(例如,与新版操作系统不兼容的时候,会不会有更新补丁)。

不论是从程序可用性的角度,还是从避免使用盗版的角度(惭愧,虽然喜欢Fireworks,却从未买过正版),寻找替代品很重要。虽然Adobe在那篇声明的后续更新中提到了“会有官方的Fireworks替代品出现”,但18个月后的今天,Adobe所说的替代品仍没有出现。Fireworks爱好者看到的,是功能越发强大的PS,是数个能够完美读取PSD文件的网页制作工具(比如Edge Reflow和Brackets),而非Adobe所说的“独立工具”。

我觉得,一个优秀的Fireworks替代品,应该具有下面的特质:

  • 强大的矢量图绘制功能:在矢量绘制方面,Fireworks的能力不亚于AI这样的专业工具,设计师可以用它设计网页,而画师也能用它创作复杂的矢量绘画;
  • 基本的位图处理能力:Fireworks提供了魔术棒、橡皮擦等基本的位图处理工具,虽然远远不及PS,却能满足一时之需;
  • 方便的对象/图层管理:在Fireworks中,每一个对象都对应一个图层,鼠标点选对象也就选中了图层,反之亦然。因为缺乏这种直接的交互方式,我至今无法习惯PS。

Smashing Magazine在2013年的一篇文章更加完整地总结了Fireworks的优点,而这些优点也正是我喜欢Fireworks的原因。这篇文章同样列举了一些第三方的替代品,例如OS X上的最佳选择Sketch,专注界面设计的Antetype、Macaw等等。可惜的是,它们要么是OS X only(比如Sketch),要么是专注界面设计,缺乏创作能力。

不过,现在有了一个新的选择:Gravit

gravit.png

Gravit最吸引我的地方,便是它的开发者以Fireworks和Freehand为榜样——实际上,不论是界面布局还是交互方式,Gravit都有一些Fireworks的影子。画布上的对象可以方便地点选,每个对象都对应着一个“图层”;矢量绘制工具初见雏形,只是功能还显得比较简陋;虽说有导入外部图片的选项,但点了之后并没有反应,也无法检查它的位图处理能力——不过,应该是“几乎没有”吧。当前的Gravit,应该可以应付一些简单的设计,但是距离Fireworks还差得远。

Gravit会成为众多“替代品”中最好的一个么?从现有的感受来看,它应该走在一条正确的路上,只是它的开发者能让它走多远,还未可知。Gravit是免费而且开源的,采用HTML5开发,桌面版本使用Node.js封装,这些现在流行的因素是一把双刃剑。至少,现在我还不会去用它。


Transparent Huge Pages & Static Huge Pages

操作系统以『页面』为单位管理内存,页面的默认大小是4096B。在现在,这个大小是有问题的。现代计算机,尤其是服务器,内存动辄上百GB,而1GB内存就会有256000个页面;每个页面都要在页表中有一个对应条目,而CPU用于缓存页表的TLB容量有限。始终使用4KB页面大小的话,运行需要使用大量内存的应用程序时,就会产生大量的TLB Miss和缺页中断。

所幸,4096B只是一个默认值,页面的大小是可以设置的。Linux内核支持两种大页面方式:静态大页面和透明大页面。例如,RHEL的文档对两者介绍如下:

简单说,超大页面是 2MB 和 1GB 大小的内存块。2MB 使用的页表可管理多 GB 内存,而 1GB 页是 TB 内存的最佳选择。超大页面必须在引导时分配。它们也很难手动管理,且经常需要更改代码以便可以有效使用。因此红帽企业版 Linux 也部署了透明超大页面 (THP)。THP 是一个提取层,可自动创建、管理和使用超大页面的大多数方面。

虽然没有用过RHEL,但在CentOS 6.5中,透明大页面是默认开启的,系统会自动为应用分配大页面。执行cat /proc/meminfo就可以看到当前的内存使用状况,其中AnonHugePages就是透明大页面的值。

针对不同分配方式对Java应用的影响,我进行了基准测试。结果表明,使用静态大页面时的性能比使用透明大页面要好大约7%,而透明大页面则比不使用大页面好大约12%。另外,网络上还有透明大页面引起性能问题的文章

要启用静态大页面,可以修改sysctl.conf

echo "vm.nr_hugepages=VALUE" >> /etc/sysctl.conf

在默认开启透明大页面的系统中,要禁用透明大页面,可以参考unix.stackexchange上的这个答案。我比较喜欢这种方式:

# put in /etc/rc.local
if test -f /sys/kernel/mm/transparent_hugepage/enabled; then
   echo never > /sys/kernel/mm/transparent_hugepage/enabled
fi
if test -f /sys/kernel/mm/transparent_hugepage/defrag; then
   echo never > /sys/kernel/mm/transparent_hugepage/defrag
fi

至于Java程序,可以用-XX:+UseLargePages来启用大页面支持;如果要显式禁用,则可以将+换成-


遇到了经典的 HashMap Race Condition

近日在公司做性能测试的时候遇到一个问题:所有请求处理线程陷在HashMap.put()或者HashMap.transfer()中,线程状态均为Runnable,CPU被占满,而系统也几乎不再响应。

搜索得知,这是一个经典的Race Condition(线程竞争)问题。因为HashMap并不是线程安全的,当多线程并发向HashMap中写入数据,并同时触发resize的时候,就可能同时陷入无限循环。

P.S. 本想翻译一下“A Beautiful Race Condition”的,后来发现已经有相关中文介绍,就用不着了。

分享几篇相关文章:

A Beautiful Race Condition by Paul Tyma

并发场景下HashMap.get导致cpu耗光的原因分析 by HelloJava

疫苗:Java HashMap的死循环 by 陈皓


重返独立博客

折腾了好长时间。从 Wordpress,到 Hexo,再到 Tumblr;从独立博客,到静态博客生成器,再到轻博客服务。今天,重新回到独立博客,拥抱 Typecho。

新的域名:metaspace.io

.io 应该是开源项目和科技初创公司最爱的域名后缀了,metaspace 则是 Java 8 内存模型中替代 Perm Generation 的部分。

特别的主机服务商:hostker

hostker 是传统 cpanel 主机和云平台服务的结合体。其空间仅支持 php 和 mysql,通过控制面板和 FTP 来管理;计费方面,却并不是包月或包年,而是像 heroku 之类的云平台那样,按照对 CPU、数据库、硬盘、流量的使用量计费。


Hello World

这是一个新博客,所以照例需要……

public static void main(String args[]) throws Exception {
    System.out.println("Hello World!");
}