Как заставить поток Java закрыть соединение с локальной нитью

Ответ 1

Если вы чувствительны, откиньтесь сейчас.

Я бы не ожидал, что это будет очень хорошо масштабироваться; он эффективно удваивает количество потоков в системе. Там могут быть некоторые варианты использования, где это приемлемо.

public class Estragon {
  public static class Vladimir {
    Vladimir() { System.out.println("Open"); }
    public void close() { System.out.println("Close");}
  }

  private static ThreadLocal<Vladimir> HOLDER = new ThreadLocal<Vladimir>() {
    @Override protected Vladimir initialValue() {
      return createResource();
    }
  };

  private static Vladimir createResource() {
    final Vladimir resource = new Vladimir();
    final Thread godot = Thread.currentThread();
    new Thread() {
      @Override public void run() {
        try {
          godot.join();
        } catch (InterruptedException e) {
          // thread dying; ignore
        } finally {
          resource.close();
        }
      }
    }.start();
    return resource;
  }

  public static Vladimir getResource() {
    return HOLDER.get();
  }
}

Лучшая обработка ошибок и т.д. остается как упражнение для исполнителя.

Вы также можете посмотреть отслеживание потоков/ресурсов в ConcurrentHashMap с другим опросом потока isAlive. Но это решение является последним средством отчаяния - объекты, вероятно, в конечном итоге будут проверяться слишком часто или слишком редко.

Я не могу думать ни о чем другом, что не связано с инструментами. АОП может работать.

Пул соединений будет моим предпочтительным вариантом.

Ответ 2

Оберните свой Runnable новым Runnable с помощью

try {
  wrappedRunnable.run();
} finally {
  doMandatoryStuff();
}

и пусть THAT будет выполняться вместо этого.

Вы даже можете сделать это в методе, например:

  Runnable closingRunnable(Runnable wrappedRunnable) {
    return new Runnable() {
      @Override
      public void run() {
        try {
          wrappedRunnable.run();
        } finally {
          doMandatoryStuff();
        }
      }
    };
  }

и вызовите этот метод, проходящий в исполняемом файле, который вы ищете.

Возможно, вы также захотите рассмотреть возможность использования Исполнителя. Это упрощает управление Runable и Callables.

Если вы используете ExecutorService, вы можете использовать его как executor.submit(closingRunnable(normalRunnable))

Если вы знаете, что вы отключите весь свой ExecutorService и хотите, чтобы соединения закрылись в этот момент, вы можете установить поток factory, который также закрывает "после выполнения всех задач и выключения, вызванных исполнителем", например:

  ExecutorService autoClosingThreadPool(int numThreads) {
    ThreadPoolExecutor threadPool = new ThreadPoolExecutor(numThreads, numThreads, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>()); // same as Executors.newFixedThreadPool
    threadPool.setThreadFactory(new ThreadFactory() {
      @Override
      public Thread newThread(Runnable r) {
        return new Thread(closingRunnable(r)); // closes it when executor is shutdown
      }
    });
    return threadPool;
  }

С точки зрения того, действительно лиMandatoryStuff может знать, было ли соединение открыто или нет ранее, одна вещь, которая приходит на ум, имеет второй ThreadLocal, который просто отслеживает, был ли он открыт или нет (например: когда соединение открыть, затем установить AtomicInteger на 2, во время очистки, проверить, не по-прежнему ли он по умолчанию, скажем, 1...)

Ответ 3

Обычная практика JDBC заключается в том, что вы закрываете Connection (и Statement и ResultSet) в том же блоке метода, который вы его приобрели.

В коде:

Connection connection = null;

try {
    connection = getConnectionSomehow();
    // Do stuff.
} finally {
    if (connection != null) {
        try {
            connection.close();
        } catch (SQLException e) {
            ignoreOrLogItButDontThrowIt(e);
        }
    }
}

Помня об этом, ваш вопрос заставляет меня думать, что в вашем дизайне что-то не так. Приобретение и закрытие таких дорогостоящих и внешних ресурсов в кратчайшие сроки спасет приложение от потенциальных утечек ресурсов и сбоев.

Если ваше первоначальное намерение заключалось в улучшении производительности соединения, вам нужно взглянуть на объединение пулов. Вы можете использовать, например, C3P0 API. Или, если это веб-приложение, используйте сервер приложений, встроенный в пул объединения, в стиле DataSource. Подробнее см. В документации по конкретным приложениям.

Ответ 4

Я не понимаю, почему вы не используете традиционный пул соединений. Но я предполагаю, что у вас есть свои причины.

Сколько у вас свободы? Поскольку некоторые структуры DI поддерживают циклы жизненного цикла объекта и переменные с областью действия (все хорошо проксированные). Не могли бы вы использовать один из них? Я думаю, что Spring сделает это все из коробки, в то время как Guice понадобится сторонняя библиотека для обработки жизненных циклов и областей потоков.

Далее, какой контроль у вас есть при создании переменной ThreadLocal или создании потоков? Я предполагаю, что у вас есть полный контроль над ThreadLocal, но он не ограничен созданием потоков?

Можете ли вы использовать Aspect-ориентированное программирование для мониторинга новых Runnable или Threads, расширяющих метод run(), чтобы включить очистку? Вам также потребуется расширить ThreadLocal, чтобы он мог зарегистрироваться.

Ответ 5

Вам нужно было открыть соединение один раз, поэтому вам также придется обращаться с закрытием в том же месте. В зависимости от вашей среды потоки могут быть повторно использованы, и вы не можете ожидать, что поток будет собирать мусор до завершения работы приложения.

Ответ 6

Я думаю, что в общем случае для этого нет хорошего решения, кроме классического: код, который получает ресурс, должен быть ответственным за его закрытие.

В конкретном случае, если вы вызываете потоки с этой степенью, вы можете передать соединение с вашими методами в начале потока либо с помощью метода, который принимает пользовательский параметр, либо через некоторую форму Injection Dependency. Затем, поскольку у вас есть код, который передает соединение, у вас есть код, который удаляет его.

В зависимости от аннотаций может работать инъекция, поскольку код, который не требует соединения, не получит его, поэтому его не нужно будет закрывать, но похоже, что ваш дизайн слишком далеко, чтобы модифицировать что-то как это.

Ответ 7

Переопределите метод get() в ThreaedLocal, чтобы он задал свойство List в подклассе. Это свойство можно легко запросить, чтобы определить, был ли метод get() вызван для определенного потока. Затем вы можете получить доступ к ThreadLocal, чтобы очистить его в этом случае.

Обновлено в ответ на комментарий

Ответ 8

То, что мы сделали, было

@Override
public void run() {
  try {
    // ...
  } finally {
    resource.close();
  }
}

В основном просто (возможно, открывать и затем) закрывать его для всех путей через поток. Если это кому-то помогает:)

Ответ 9

Я смотрю на ту же проблему. Похоже, что до сих пор вы должны использовать finalize(), хотя теперь это устарело. Поскольку задачи передаются какому-либо исполнителю, вы никогда не узнаете, когда поток точно выйдет, если только исполнитель не покажет вам это, что означает, что вы в какой-то степени можете контролировать исполнителя.

Например, если вы строите Executor путем расширения ThreadPoolExecutor, вы можете переопределить методы afterExecution() и terminated(), чтобы выполнить это. Первый для потока, выходящего ненормально, а второй для нормального.