http://huangzhimin.com/2012/11/14/jruby-at-openfeint-jruby-migration-success-story/ 参考一下经验，目前大家遇到的问题是一下有 C 依赖的 Gem 包直接用 jruby 调用效率低下。可以多和上游社区多做反馈，做一下 patch 就能解决。不能解决的模块拆出来使用 SOA 架构分离。你的项目可以一开始就在单纯的 rails 上开发，然后做 JRuby 集成测试来找问题。附上的链接也是通过测试来验证选型的。

视频可以过来这里看，http://ruby-china.org/topics/7264，上面有说遇到的一些坑以及他们是如何解决的（依稀记得是要解决 json 数据的 hashcode 不相同的问题）

@xds2000 C 扩展慢的问题不好解决吧？ Ruby 写 C 扩展很容易的一个原因是 Ruby 的 GC 是保守式 GC, 保守式 GC 可以通过扫描栈获得变量存活信息而不用在 C 代码中手动释放对象. 而 JNI 完全就不是这么回事，你要各种手动 JNIEnv->releaseXXX, 而且对象进入到 C 实现的代码中前，指针会在内存中 pin 住，直接脱离 GC 的 compact 阶段... 这种异构导致要么得用 Java 重写相应的 C 扩展，要么得在调用前走好厚的 FFI 包装，本来能变快的东西却变慢了...

@luikore 用 JRuby 的目的就是利用它的多线程特性和 VM。我看过最近的 jruby core member 在 twitter 上说 FFI 还不如用 C 来写。但如何从@flyerhzm 的迁移经验还是避开这种带 C 依赖的。直接用 JAVA 重新实现带 C 依赖的，效果会更明显。可能这个趋势应该要提倡。

#4 楼 @xds2000 Ruby 2.0 的 COW friendly GC 的话，多进程部署各种优势啊，而且并行和并发是两回事，EventMachine 就是单线程内处理高并发的...

#5 楼 @luikore 主要还是省内存，Ruby 2.0 对生产环境还是有些远

#5 楼 @luikore Ruby 1.8 的时候就宣传说 1.9 的 VM 进程是 COW 的，几年后真的到了 1.9 就开始宣传 2.0 就会是真的了。2.0 的具体变更我没有太关注，但根据 Matz 本人的说法，2.0 其实是个小版本更新，不知道 COW friendly 会不会真的来了？

#7 楼 @lgn21st

2.0-preview1 的 ChangeLog 里有：

sat Jan 7 22:25:50 2012 Narihiro Nakamura [email protected]

• gc.c: use Bitmap Marking algorithm to avoid copy-on-write of memory pages. See [ruby-dev:45085] [Feature #5839] [ruby-core:41916].

但 1.9.3-p327 没有

另外 1.9.3 已经是使用了 lazy-sweep 手段的增量式 gc, 不会有像 1.8 那样的卡住的情况了

再另外同样是这个作者 nari 已经做了 parallel gc 的原型，据称可以提升 40% 左右的 gc 速度

@lgn21st 再附带一提，nari 叫中村成洋，冰激凌工人出身，写了一本书：GC 算法实装, 暂时只有日文版，看了可以对现代高级语言的 GC 有更好的认识哦 (我不懂日语只看了书中的代码...)

#9 楼 @luikore 想办法请他明年来参加中国的 Ruby 大会。

嗯，这么多人回复，让我顿时回复了信心！

#9 楼 @luikore 你说的「GC 算法实装」跟这本徹底解剖「G1GC」実装編是同一本东西么

建议关注一下 Charles Oliver Nutter twitter @headius , 看看今天贴出来的 jruby profile 的一个脚本。 https://gist.github.com/4343186

#12 楼 @ywjno 不是，书名是 ガベージコレクションのアルゴリズムと実装 (图书馆里超容易被分类到环境工程类 orz), 内容是由浅入深介绍各种 GC 算法的，不是对特定 GC 的解读

#14 楼 @luikore 继续找了下资料貌似还真不是同一本书，看网上的评价貌似这本书讲得不错，有机会让人从日本给带一本回来

一个月后再回来，JRuby 本身如何还无法判断，但是和公司原有的开发和部署环境集成太痛苦了，包的版本，用公司的一些包的问题，关键是还得在 Ruby 中调用 Java 代码，实在是相当难看！