我听说过JRuby很棒的东西，我知道你可以在不知道任何Java的情况下运行它。我的开发技巧很强，Java不是我所知道的工具之一。它是一个庞大的工具，有许多附带工具，如Maven / Ant / JUnit等。
仅出于性能原因，是否值得将我当前的Rails应用程序移至JRuby？也许如果我选择一些基本的Java，那么可以有一些不太明显的好处，比如更好的调试/性能优化工具？
会喜欢这方面的建议。
答案 0 :(得分：26)
我认为你几乎已经钉了它。
JRuby只是另一个Ruby执行引擎，就像MRI，YARV，IronRuby，Rubinius，MacRuby，MagLev，SmallRuby，Ruby.NET，XRuby，RubyGoLightly，tinyrb，HotRuby，BlueRuby，Red Sun等等。 / p>
主要区别是：
可移植性：例如，YARV仅在x86 32位Linux上得到官方支持。 OSX或Windows或64位Linux不支持它。 Rubinius只适用于Unix，而不适用于Windows。 JRuby OTOH运行到处：台式机，服务器，电话，App Engine，你可以命名它。它运行在Oracle JDK，OpenJDK，IBM J9，Apple SoyLatte，RedHat IcedTea和Oracle JRockit JVM（可能还有其他几个我忘记的）以及Dalvik VM上。它运行在Windows，Linux，OSX，Solaris，几个BSD，其他专有和开放的Unices，OpenVMS和几个大型机操作系统，Android和Google App Engine上。实际上，在Windows上，JRuby传递的RubySpec测试比“Ruby”（意思是MRI或YARV）更多！
可扩展性：在JRuby上运行的Ruby程序可以使用任意Java库。通过JRuby-FFI，他们还可以使用任意C库。借助JRuby 1.6中新的C扩展支持，它们甚至可以使用大量的MRI和YARV C扩展，例如Mongrel。 （请注意，“Java”或“C”库实际上并不意味着用这些语言编写，它只表示使用Java或C API。它们可以用Scala或Clojure或C ++或Haskell编写。）
< / LI>工具：每当有人为YARV或MRI（例如memprof）编写新工具时，事实证明JRuby在5年前已经有了一个工具，它做了同样的事情，只是更好。 Java生态系统有一些最好的“运行时行为理解”工具（这是我刚刚编写的术语，我的意思不仅仅是简单的分析，我的意思是深入理解程序在运行时的作用的工具，它的性能特征是什么，瓶颈在哪里，内存在哪里，最重要的是为什么所有这些都在发生？）和市场上的可视化，以及几乎所有这些都与JRuby一起工作，至少在某种程度上。
部署：假设您的目标系统已经安装了JVM，部署JRuby应用程序（我不只是谈论Rails，我也指台式机，移动设备，其他类型的服务器）实际上就是复制一个JAR（或WAR）和一个双击。
性能：JRuby的启动开销要高得多。作为回报，您可以获得更高的吞吐量实际上，这意味着将Rails应用程序部署到JRuby是一个好主意，就像运行集成测试一样，但对于开发人员单元测试和脚本，MRI，YARV或Rubinius是更好的选择。请注意，许多Rails开发人员只需在MRI和集成测试上开发和单元测试，并在JRuby上进行部署。没有必要为所有事情选择一个执行引擎。
并发性：JRuby同时运行Ruby线程。这意味着两件事：如果您的锁定正确，您的程序将运行得更快，如果您的锁定不正确，您的程序将会中断。 （不幸的是，MRI，YARV和Rubinius都没有同时运行线程，因此仍有一些破碎的多线程Ruby代码不知道它已经坏了，因为很明显，如果存在实际的并发性，并发错误只会出现。）
< / LI>平台（这与可移植性有些相关）：有一些令人惊叹的Java平台，例如： Azul JCA具有768 GiBytes RAM和864 CPU内核，专为内存安全，指针安全，垃圾收集，面向对象语言而设计。 Android系统。 Google App Engine。所有这些都运行JRuby。
答案 1 :(得分：5)
我会修改彼得稍微说的话。与标准Ruby相比，JRuby 可能使用更多内存，但这通常是因为您在单个进程中完成了使用Ruby需要多个进程的工作。
您应该使用单个JRuby运行时尝试Rails.threadsafe!选项（例如，带有--threadsafe选项的Trinidad gem）。我们已经听过几个故事，它可以为您提供出色的性能和较低的内存使用率，同时通过一个流程利用多个CPU内核。
答案 2 :(得分：4)
JRuby是少数使用本机线程的实现之一。所以如果你想做一些多线程，那就去吧。
就托管而言，你必须将你的应用程序放在某种java容器中，我个人认为这比使用乘客（适用于Rack应用程序）要简单得多
我使用JRuby作为应用程序，因为我们通过JMS进行通信，它工作正常，但如果我没有使用任何Java，我肯定会坚持使用CRuby。我最大的好处是，在测试中，运行测试需要永久使用JRuby，因为每次运行它时都必须启动VM。这使得TDD变得更加困难，因为它会严重影响您的测试时间。
答案 3 :(得分：4)
如果你在Windows上，Jruby有优势。它支持64位，您可以使用许多专有数据库和标准JDBC驱动程序。
答案 4 :(得分：2)
最新版本比Ruby快得多，但也使用了更多的内存。如果这是你使用JRuby的唯一原因，除非你有一个特定的性能需求，否则我不会打扰，只是因为，虽然它非常受欢迎，但它不太适合托管，与标准相比，人们使用它的人数较少红宝石。话虽如此，使用JRuby还有许多其他原因，例如需要与现有Java代码进行互操作，以及需要在Java已被运营部门“祝福”的环境中进行部署，而Ruby则没有。