小编Ger*_*ler的帖子

我想知道JDK 7版本中"垃圾优先"(G1)收集器的官方状态是什么.我想使用G1作为CMS的低暂停gc替代品,但前提是我真的可以信赖它的稳健性.

在JDK 7推出之前,G1被宣传为闪亮的新gc将取代CMS收集器,甚至成为JDK 7中的默认gc.但是,现在使用Oracle JDK 7u1,G1不是我拥有的任何机器上的默认gc试过.

即使在JDK 7中-XX:+UnlockExperimentalVMOptions使用时不再需要指定-XX:+UseG1GC,它仍然是官方完全未记录的JVM功能:

关于G1的Java 7(JDK 7)垃圾收集和文档

我发现提到G1的唯一正式文件已经过时了,并且在JDK 7发布之前很久就写完了:

http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html

例如,官方的"Java HotSpot VM Options"文档(http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html)记录了如何启用和调整其他收集器,但是甚至没有提到G1的存在.好像它不存在!

这很令人困惑,我想知道G1的真实状态及其未来是什么.它真的稳定吗？是否已解决剩余的问题(如泄漏,虚假崩溃和缺少仪器支持)？如果是这样,为什么Oracle将G1GC视为无证(令人尴尬？)的秘密？G1可能是一个失败的项目,现在已经默默地停止了吗？或者我需要支付文档和支持吗？还是仅仅是测试版？有人可以告诉我这里发生了什么吗？

EJB 3.0规范不允许无状态会话bean的业务方法创建新线程.这是为什么？创建仅执行原始计算并且从不调用应用程序服务器的其他工作线程有什么问题？

比如说,我的会话bean实现了一个允许用户上传图像的服务,而业务方法对这些图像进行了cpu密集型图像处理.那么即使机器有8个或更多核心,它也只能使用一个cpu核心来完成这项工作？如果我利用第三方图像处理库,在内部创建工作线程,我也会违反EJB规范,即使该库和这些线程根本不与EJB容器有关.这似乎不对.

如果我忽略EJB规则并仍然创建一些工作线程来进行cpu密集处理会发生什么？当然这些线程永远不会触及任何app服务器对象,bean线程会在返回之前加入它们.还能发生什么不好的事吗？

JDK文档说，如果当前在InterruptibleChannel的io操作中阻塞的线程被中断，则通道将关闭，并引发ClosedByInterruptException。但是，使用FileChannel时出现不同的行为：

public class Main implements Runnable {

public static void main(String[] args) throws Exception {
    Thread thread = new Thread(new Main());
    thread.start();
    Thread.sleep(500);
    thread.interrupt();
    thread.join();
}

public void run() {
    try {
        readFile();
    } catch (IOException ex) {
        ex.printStackTrace();
    }
}

private void readFile() throws IOException {
    FileInputStream in = new FileInputStream("large_file");
    FileChannel channel = in.getChannel();
    ByteBuffer buffer = ByteBuffer.allocate(0x10000);
    for (;;) {
        buffer.clear();
        // Thread.currentThread().interrupt();
        int r = channel.read(buffer);
        if (Thread.currentThread().isInterrupted()) {
            System.out.println("thread interrupted");
            if (!channel.isOpen())
                System.out.println("channel closed");
        } …