空间爆了,滥用System.out啊

 

最近,系统有出现磁盘空间被耗尽的问题(磁盘空间20G,扣除系统及部署后可用空间14G,应用程序部署在linux上);原来怀疑是应用程序中使用的文件缓存太大,占用了太大的资源;不过检查的时候发现缓存文件目录 仅占用了 3.8G,应用程序下的所有目录总计占用6G,达不到爆满的情况;

 

        在检查的时候,发现日志文件有问题,系统使用了log4j的日志框架,log4j.xml采用的配置是:

 

日志文件按照容量大小拆分,最大10M;

<appender name="App" class="org.apache.log4j.RollingFileAppender">

        <param name="File" value="../logs/mapp-server.log" />

        <param name="MaxFileSize" value="10240KB" />

        <param name="MaxBackupIndex" value="3" />

        <param name="encoding" value="gbk" />

        <layout class="org.apache.log4j.PatternLayout">

                <param name="ConversionPattern" value="%d{yyyy-MM-dd HH:mm:ss} [%t] %-5p [%c-%L] - %m%n" />

                 </layout>

</appender>

 

不过生成的日志文件每个都不止10M;觉得很奇怪;

昨天干脆修改为 日志文件按天拆分;

 <appender name="App" class="org.apache.log4j.DailyRollingFileAppender">

        <param name="File" value="../logs/mapp-server.log" />

        <param name="DatePattern" value="'.'yyyy-MM-dd'.log'" />

        <param name="encoding" value="gbk" />

        <layout class="org.apache.log4j.PatternLayout">

                <param name="ConversionPattern" value="%d{yyyy-MM-dd HH:mm:ss} [%t] %-5p [%c-%L] - %m%n" />

        </layout>

  </appender>

 

今天早上检查日志的时候,发现2012-11-15的日志已经生成; ll 命令发现,2012-11-15的日志文件超大300多M;再细看,发现2012-11-15的日志文件最近的写入日期是 11-16 09多;觉得不应该;


 

 

红色部分,很有问题;

使用tail -f 检查日志文件,发现文件内容还在刷新;而且输出的日志信息不是log4j日志框架所输出的格式;初步怀疑是System.out搞的鬼;

 

搜索工程源码目录,在一个对外接口的方法中找到System.out,经过比对,可以确认这个输出的内容就是日志中一直刷新的内容;而且,系统上线之后,该方法是对外统一入口,访问量很大;输出非常频繁;

 

后面将这个System.out 修改为 logger.debug 输出,一切OK;

 

那么为什么会出现这个问题呢?

System.out输出是输出到控制台啊,为什么会搞到日志文件中呢;

我回想起之前查看weblogic的启动命令(startWeblogic.sh)的时候,出现的一段内容:

 

 

其中标红的一段,被修改为nohup >>XXXX.log;

这个就表示了,控制台日志被输出到了日志文件了,也就是说System.out还是会输出日志文件了;

 

但是日志文件,在11.16被框架修改了名称为 xxxx.2012-11-15.log,那么为什么System.out还依旧那么的执着呢,不是输出到新的文件中呢?反而非要死乞白赖的输出到改名后的文件呢;;

这个是nohup的问题了。。nohup启动之后,指定输出文件,那么就生成了一个句柄;这个句柄一直在,认目标;中间如果文件被改名了,那么还是输出到改名后的文件;而不是新的同名文件;如果文件很不幸被删除了,,那么恭喜你,nohup还会一直输出,而且句柄不释放,空间不释放,而且还不断增加,而你查目录占用空间还查不出来;恭喜你,一段时间之后,你会发现空间爆了;

 

nohup没有错,人家就是这个样子的;

System.out也木有错,说好了是输出带控制台;

错的是有了日志框架不用,非要用System.out;尼玛,有不有,以后在正式提交的代码中,严禁看到System.out;

 

PS:printStackTrace 和 System.out是一个玩意儿啊。。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: `System.gc()` 是 Java 程序中的一个方法,它是在 Java 的 `java.lang` 包中的。这个方法的作用是请求 JVM 进行垃圾回收,但并不保证 JVM 一定会立即回收垃圾。它只是一个建议,由 JVM 决定是否执行回收操作。实际上,现代的 JVM 实现已经很智能,不需要开发人员明确地调用此方法来进行垃圾回收。 ### 回答2: System.gc();是Java中的一个方法调用,用于显示地触发垃圾回收。垃圾回收是Java虚拟机在运行时自动管理内存的一种机制,它负责自动回收不再被使用的对象的内存空间。当程序运行时,创建了一些对象,并且这些对象不再被引用时,Java虚拟机会自动回收这些对象所占用的内存空间,释放资源,这个过程就是垃圾回收。 而System.gc()方法的作用就是显式地调用垃圾回收器。虽然Java虚拟机会根据自身的策略自动触发垃圾回收,但是我们也可以通过调用System.gc()方法来建议虚拟机执行垃圾回收操作。调用System.gc()并不是立即执行垃圾回收,而是向垃圾回收器发送一个请求,告诉它有待回收的对象可以进行回收。 需要注意的是,System.gc()方法的调用并不会立即释放所有内存,也不能保证垃圾回收一定会执行。垃圾回收的具体执行时间是由JVM决定的,而且该方法的执行会造成一定的性能损失。因此,在编写代码时,我们不应该过分依赖于System.gc(),而是应该编写良好的代码结构和逻辑,避免出现内存泄漏等问题。 总之,System.gc()方法是用来手动触发垃圾回收的,它向垃圾回收器发送一个请求,告诉它有待回收的对象可以进行回收。但是需要注意的是,调用System.gc()并不能保证垃圾回收一定会执行,也不能立即释放所有内存,因此在编写代码时应该合理使用,不过度依赖于该方法。 ### 回答3: System.gc()是Java中的一个方法,用于显式地请求垃圾回收器进行垃圾回收。 在Java中,垃圾回收器负责自动回收不再使用的内存,释放掉这些内存供其他程序使用,从而避免了内存泄漏的问题。系统会自动进行垃圾回收,但是我们也可以使用System.gc()方法来主动触发垃圾回收。 当我们调用System.gc()方法时,会向JVM发送一个垃圾回收的请求,但是具体是否立即进行垃圾回收以及回收的效果,取决于JVM的实现。 值得注意的是,尽管我们可以调用System.gc()方法来主动触发垃圾回收,但是这并不意味着每次调用都会导致垃圾回收的立即执行。实际上,JVM会根据自身的策略和算法来决定何时进行垃圾回收,以及要回收多少的内存。 在一般情况下,我们并不需要手动调用System.gc()方法,因为JVM能够根据需要自动进行垃圾回收。只有在某些特殊情况下,比如我们需要尽快回收大量的内存时,可能会使用System.gc()方法来主动触发垃圾回收。 总之,System.gc()方法是Java中一个用于主动触发垃圾回收的方法。但是我们要注意,不要滥用这个方法,因为JVM能够自动进行垃圾回收,并且过多地调用System.gc()方法可能会影响程序的性能。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值