我有一个Spring应用程序，它有几个scheduled方法
似乎Lo4J停止滚动到新文件并在应用程序运行一段时间后增长到10 GB。
所有配置看起来都很好，我只使用notepad ++打开日志文件（意味着编辑器没有锁定日志文件）
所以我思考可能在应用程序中运行另一个线程。我想回想一下当前应用中的任何多线程实现。
那么@Scheduled方法是否可能导致问题？
答案 0 :(得分：2)
@Scheduled导致代码在一个单独的线程中运行，不一定是新的，因为它可能来自线程池。
日志文件的非翻转发生是因为当log4j尝试重命名文件以进行翻转时，某些应用程序线程会在该精确时刻记录到该文件。
根据log4j滚动文件实现RollingFileAppender的代码，当翻转时间到来时（调用rollOver()方法），尝试重命名该文件。
如果文件被锁定，则不会发生翻转，并且log4j继续使用相同的文件，直到下次触发翻转策略并再次尝试重命名为止。
因此@Scheduled注释可能对此有所贡献，但如果有大量请求（如果它是Web应用程序等），它可能不是唯一负责的。
要减少翻转失败的可能性，请尝试将@Scheduled个主题更改为 不同 时刻，而不是发生翻转尝试时。< / p>
同时将日志记录级别降低到ERROR将降低翻转失败的可能性。另请参阅How to find which thread is locking a file。
答案 1 :(得分：0)
它应该使用配置的线程池分配的其中一个线程。每次执行一个计划任务时都会拾取线程，一旦任务完成，线程将被释放回池中。记录量取决于任务运行的频率和时间。你有多少日志语句。所以，除非有 A LOT 的日志记录，否则可能不是你的问题。
您应该在调度程序配置中使用与此类似的内容来确定池大小。您的池大小也应由计算机上的可用线程确定。核心数，每个核心的线程数，jvms等。
<task:annotation-driven scheduler="taskScheduler"/>
<task:scheduler id="taskScheduler" pool-size="2"/>