• 关于 java讨论问题 的搜索结果

问题

[@倚贤][¥20]与技术完全无关,却富有挑战的问题

嘟嘟老爸 2019-12-01 20:26:43 627 浏览量 回答数 2

回答

枚举单例是使用一个实例在 Java 中实现单例模式的新方法。虽然Java中的单例模式存在很长时间,但枚举单例是相对较新的概念,在引入Enum作为关键字和功能之后,从Java5开始在实践中。本文与之前关于 Singleton 的内容有些相关, 其中讨论了有关 Singleton 模式的面试中的常见问题, 以及 10 个 Java 枚举示例, 其中我们看到了如何通用枚举可以。这篇文章是关于为什么我们应该使用Eeame作为Java中的单例,它比传统的单例方法相比有什么好处等等。

YDYK 2020-04-25 00:12:16 0 浏览量 回答数 0

回答

设置Tomcat启动的初始内存其初始空间(即-Xms)是物理内存的1/64,最大空间(-Xmx)是物理内存的1/4。 可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置 三、实例,以下给出1G内存环境下java jvm 的参数设置参考: JAVA_OPTS="-server -Xms800m -Xmx800m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true " JAVA_OPTS="-server -Xms768m -Xmx768m -XX:PermSize=128m -XX:MaxPermSize=256m -XX: NewSize=192m -XX:MaxNewSize=384m" CATALINA_OPTS="-server -Xms768m -Xmx768m -XX:PermSize=128m -XX:MaxPermSize=256m -XX:NewSize=192m -XX:MaxNewSize=384m" Linux: 在/usr/local/apache-tomcat-5.5.23/bin 目录下的catalina.sh添加: JAVA_OPTS='-Xms512m -Xmx1024m'要加“m”说明是MB,否则就是KB了,在启动tomcat时会 报内存不足。 -Xms:初始值-Xmx:最大值-Xmn:最小值 Windows 在catalina.bat最前面加入set JAVA_OPTS=-Xms128m -Xmx350m 如果用startup.bat启动tomcat,OK设置生效.够成功的分配200M内存. 但是如果不是执行startup.bat启动tomcat而是利用windows的系统服务启动tomcat服务,上面的设置就不生效了,就是说set JAVA_OPTS=-Xms128m -Xmx350m 没起作用.上面分配200M内存就OOM了.. windows服务执行的是bintomcat.exe.他读取注册表中的值,而不是catalina.bat的设置. 解决办法: 修改注册表HKEY_LOCAL_MACHINESOFTWAREApache Software FoundationTomcat Service ManagerTomcat5ParametersJavaOptions 原值为-Dcatalina.home="C:ApacheGroupTomcat 5.0"-Djava.endorsed.dirs="C:ApacheGroupTomcat 5.0commonendorsed"-Xrs加入 -Xms300m -Xmx350m 重起tomcat服务,设置生效 答案2Tomcat 的JVM 内存溢出问题的解决关键字: tomcat 的jvm 内存溢出问题的解决 最近在熟悉一个开发了有几年的项目,需要把数据库从mysql移植到oracle,首先把jdbc的连接指向mysql,打包放到tomcat里面,可以跑起来,没有问题,可是当把jdbc连接指向oracle的时候,tomcat就连续抛java.lang.OutOfMemoryError的错误,上网google了一下,了解了一下tomcat的运行机制,也解决了问题,share出来,以备查。 1、首先是:java.lang.OutOfMemoryError: Java heap space 解释: Heap size 设置 JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heap size的值,其初始空间(即-Xms)是物理内存的1/64,最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。 提示:在JVM中如果98%的时间是用于GC且可用的Heap size 不足2%的时候将抛出此异常信息。 提示:Heap Size 最大不要超过可用物理内存的80%,一般的要将-Xms和-Xmx选项设置为相同,而-Xmn为1/4的-Xmx值。 解决方法: 手动设置Heap size 修改TOMCAT_HOME/bin/catalina.bat,在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行: Java代码 set JAVA_OPTS=%JAVA_OPTS% -server -Xms800m -Xmx800m -XX:MaxNewSize=256m set JAVA_OPTS=%JAVA_OPTS% -server -Xms800m -Xmx800m -XX:MaxNewSize=256m 或修改catalina.sh 在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行: JAVA_OPTS="$JAVA_OPTS -server -Xms800m -Xmx800m -XX:MaxNewSize=256m" 2、其次是:java.lang.OutOfMemoryError: PermGen space 原因: PermGen space的全称是Permanent Generation space,是指内存的永久保存区域,这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中,它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理,所以如果你的应用中有很CLASS的话,就很可能出现PermGen space错误,这种错误常见在web服务器对JSP进行pre compile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。 解决方法: 1. 手动设置MaxPermSize大小 修改TOMCAT_HOME/bin/catalina.bat(Linux下为catalina.sh),在Java代码 “echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行: set JAVA_OPTS=%JAVA_OPTS% -server -XX:PermSize=128M -XX:MaxPermSize=512m “echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行: set JAVA_OPTS=%JAVA_OPTS% -server -XX:PermSize=128M -XX:MaxPermSize=512m catalina.sh下为: Java代码 JAVA_OPTS="$JAVA_OPTS -server -XX:PermSize=128M -XX:MaxPermSize=512m" JAVA_OPTS="$JAVA_OPTS -server -XX:PermSize=128M -XX:MaxPermSize=512m" 另外看到了另外一个帖子,觉得挺好,摘抄如下: 分析java.lang.OutOfMemoryError: PermGen space 发现很多人把问题归因于: spring,hibernate,tomcat,因为他们动态产生类,导致JVM中的permanent heap溢出 。然后解决方法众说纷纭,有人说升级 tomcat版本到最新甚至干脆不用tomcat。还有人怀疑spring的问题,在spring论坛上讨论很激烈,因为spring在AOP时使用CBLIB会动态产生很多类。 但问题是为什么这些王牌的开源会出现同一个问题呢,那么是不是更基础的原因呢?tomcat在Q&A很隐晦的回答了这一点,我们知道这个问题,但这个问题是由一个更基础的问题产生。 于是有人对更基础的JVM做了检查,发现了问题的关键。原来SUN 的JVM把内存分了不同的区,其中一个就是permenter区用来存放用得非常多的类和类描述。本来SUN设计的时候认为这个区域在JVM启动的时候就固定了,但他没有想到现在动态会用得这么广泛。而且这个区域有特殊的垃圾收回机制,现在的问题是动态加载类到这个区域后,gc根本没办法回收! 对于以上两个问题,我的处理是: 在catalina.bat的第一行增加: Java代码 :set JAVA_OPTS=-Xms64m -Xmx256m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m 在catalina.sh的第一行增加: Java代码 :JAVA_OPTS=-Xms64m -Xmx256m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m

a123456678 2019-12-02 02:02:45 0 浏览量 回答数 0

云原生Knative训练营

免费开通产品,还有CNCF指尖陀螺等你拿哦~

问题

Cassandra是否支持java10 ?

养狐狸的猫 2019-12-01 19:56:25 9 浏览量 回答数 0

回答

在Java5之前的版本,使用双重检查锁定创建单例Singleton时,如果多个线程试图同时创建Singleton实例,则可能有多个Singleton实例被创建。从Java5开始,使用Enum创建线程安全的Singleton很容易。但如果面试官坚持双重检查锁定,那么你必须为他们编写代码。记得使用volatile变量。 为什么枚举单例在Java中更好 枚举单例是使用一个实例在Java中实现单例模式的新方法。虽然Java中的单例模式存在很长时间,但枚举单例是相对较新的概念,在引入Enum作为关键字和功能之后,从Java5开始在实践中。本文与之前关于Singleton的内容有些相关,其中讨论了有关Singleton模式的面试中的常见问题,以及10个Java枚举示例,其中我们看到了如何通用枚举可以。这篇文章是关于为什么我们应该使用Eeame作为Java中的单例,它比传统的单例方法相比有什么好处等等。 Java枚举和单例模式 Java中的枚举单例模式是使用枚举在Java中实现单例模式。单例模式在Java中早有应用,但使用枚举类型创建单例模式时间却不长.如果感兴趣,你可以了解下构建者设计模式和装饰器设计模式。 1)枚举单例易于书写 这是迄今为止最大的优势,如果你在Java5之前一直在编写单例,你知道,即使双检查锁定,你仍可以有多个实例。虽然这个问题通过Java内存模型的改进已经解决了,从Java5开始的volatile类型变量提供了保证,但是对于许多初学者来说,编写起来仍然很棘手。与同步双检查锁定相比,枚举单例实在是太简单了。如果你不相信,那就比较一下下面的传统双检查锁定单例和枚举单例的代码: 在Java中使用枚举的单例 这是我们通常声明枚举的单例的方式,它可能包含实例变量和实例方法,但为了简单起见,我没有使用任何实例方法,只是要注意,如果你使用的实例方法且该方法能改变对象的状态的话,则需要确保该方法的线程安全。默认情况下,创建枚举实例是线程安全的,但Enum上的任何其他方法是否线程安全都是程序员的责任。 你可以通过EasySingleton.INSTANCE来处理它,这比在单例上调用getInstance()方法容易得多。 具有双检查锁定的单例示例 下面的代码是单例模式中双重检查锁定的示例,此处的getInstance()方法检查两次,以查看INSTANCE是否为空,这就是为什么它被称为双检查锁定模式,请记住,双检查锁定是代理之前Java5,但Java5内存模型中易失变量的干扰,它应该工作完美。 你可以调用DoubleCheckedLockingSingleton.getInstance()来获取此单例类的访问权限。 现在,只需查看创建延迟加载的线程安全的Singleton所需的代码量。使用枚举单例模式,你可以在一行中具有该模式,因为创建枚举实例是线程安全的,并且由JVM进行。 人们可能会争辩说,有更好的方法来编写Singleton而不是双检查锁定方法,但每种方法都有自己的优点和缺点,就像我最喜欢在类加载时创建的静态字段Singleton,如下面所示,但请记住,这不是一个延迟加载单例: 单例模式用静态工厂方法 这是我最喜欢的在Java中影响Singleton模式的方法之一,因为Singleton实例是静态的,并且最后一个变量在类首次加载到内存时初始化,因此实例的创建本质上是线程安全的。 你可以调用Singleton.getSingleton()来获取此类的访问权限。 2)枚举单例自行处理序列化 传统单例的另一个问题是,一旦实现可序列化接口,它们就不再是Singleton,因为readObject()方法总是返回一个新实例,就像Java中的构造函数一样。通过使用readResolve()方法,通过在以下示例中替换Singeton来避免这种情况: 如果Singleton类保持内部状态,这将变得更加复杂,因为你需要标记为transient(不被序列化),但使用枚举单例,序列化由JVM进行。 3)创建枚举实例是线程安全的 如第1点所述,因为Enum实例的创建在默认情况下是线程安全的,你无需担心是否要做双重检查锁定。 总之,在保证序列化和线程安全的情况下,使用两行代码枚举单例模式是在Java5以后的世界中创建Singleton的最佳方式。你仍然可以使用其他流行的方法,如你觉得更好,欢迎讨论。

珍宝珠 2020-02-07 16:58:59 0 浏览量 回答数 0

问题

荆门开诊断证明-scc

游客5k2abgdj3m2ti 2019-12-01 22:09:00 1 浏览量 回答数 0

回答

给你推荐几个 java 的 schema migrationhttps://flywaydb.org/https://blog.jooq.org/tag/database-migration/https://www.liquibase.org/还有两篇关于这个问题的讨论问题https://stackoverflow.com/questions/46956753/database-independent-data-migrationhttps://www.reddit.com/r/java/comments/594kf0/best_library_for_writing_db_migration_tool/

倚贤 2019-12-02 01:44:39 0 浏览量 回答数 0

回答

字符串在Java中是不可变的,因为String对象缓存在String池中。由于缓存的字符串在多个客户之间共享,因此始终存在风险,其中一个客户的操作会影响所有其他客户。例如,如果一段代码将String“Test”的值更改为“TEST”,则所有其他客户也将看到该值。由于String对象的缓存性能是很重要的一方面,因此通过使String类不可变来避免这种风险。 同时,String是final的,因此没有人可以通过扩展和覆盖行为来破坏String类的不变性、缓存、散列值的计算等。String类不可变的另一个原因可能是由于HashMap。 由于把字符串作为HashMap键很受欢迎。对于键值来说,重要的是它们是不可变的,以便用它们检索存储在HashMap中的值对象。由于HashMap的工作原理是散列,因此需要具有相同的值才能正常运行。如果在插入后修改了String的内容,可变的String将在插入和检索时生成两个不同的哈希码,可能会丢失Map中的值对象。 如果你是印度板球迷,你可能能够与我的下一句话联系起来。字符串是Java的VVSLaxman,即非常特殊的类。我还没有看到一个没有使用String编写的Java程序。这就是为什么对String的充分理解对于Java开发人员来说非常重要。 String作为数据类型,传输对象和中间人角色的重要性和流行性也使这个问题在Java面试中很常见。 为什么String在Java中是不可变的是Java中最常被问到的字符串访问问题之一,它首先讨论了什么是String,Java中的String如何与C和C++中的String不同,然后转向在Java中什么是不可变对象,不可变对象有什么好处,为什么要使用它们以及应该使用哪些场景。这个问题有时也会问:“为什么String在Java中是final的”。在类似的说明中,如果你正在准备Java面试,我建议你看看Java编程面试公开书,这是高级和中级Java程序员的优秀资源。它包含来自所有重要Java主题的问题,包括多线程,集合,GC,JVM内部以及Spring和Hibernate框架等。 正如我所说,这个问题可能有很多可能的答案,而String类的唯一设计者可以放心地回答它。我在JoshuaBloch的EffectiveJava书中期待一些线索,但他也没有提到它。我认为以下几点解释了为什么String类在Java中是不可变的或final的: 1)想象字符串池没有使字符串不可变,它根本不可能,因为在字符串池的情况下,一个字符串对象/文字,例如“Test”已被许多参考变量引用,因此如果其中任何一个更改了值,其他参数将自动受到影响,即假设 现在字符串B调用"Test".toUpperCase(),将同一个对象改为“TEST”,所以A也是“TEST”,这不是期望的结果。 下图显示了如何在堆内存和字符串池中创建字符串。 2)字符串已被广泛用作许多Java类的参数,例如,为了打开网络连接,你可以将主机名和端口号作为字符串传递,你可以将数据库URL作为字符串传递,以打开数据库连接,你可以通过将文件名作为参数传递给FileI/O类来打开Java中的任何文件。如果String不是不可变的,这将导致严重的安全威胁,我的意思是有人可以访问他有权授权的任何文件,然后可以故意或意外地更改文件名并获得对该文件的访问权限。由于不变性,你无需担心这种威胁。这个原因也说明了,为什么String在Java中是最终的,通过使java.lang.Stringfinal,Java设计者确保没有人覆盖String类的任何行为。 3)由于String是不可变的,它可以安全地共享许多线程,这对于多线程编程非常重要.并且避免了Java中的同步问题,不变性也使得String实例在Java中是线程安全的,这意味着你不需要从外部同步String操作。关于String的另一个要点是由截取字符串SubString引起的内存泄漏,这不是与线程相关的问题,但也是需要注意的。 4)为什么String在Java中是不可变的另一个原因是允许String缓存其哈希码,Java中的不可变String缓存其哈希码,并且不会在每次调用String的hashcode方法时重新计算,这使得它在Java中的HashMap中使用的HashMap键非常快。简而言之,因为String是不可变的,所以没有人可以在创建后更改其内容,这保证了String的hashCode在多次调用时是相同的。 5)String不可变的绝对最重要的原因是它被类加载机制使用,因此具有深刻和基本的安全考虑。如果String是可变的,加载“java.io.Writer”的请求可能已被更改为加载“mil.vogoon.DiskErasingWriter”.安全性和字符串池是使字符串不可变的主要原因。顺便说一句,上面的理由很好回答另一个Java面试问题:“为什么String在Java中是最终的”。要想是不可变的,你必须是最终的,这样你的子类不会破坏不变性。你怎么看?

珍宝珠 2020-02-07 16:52:57 0 浏览量 回答数 0

回答

阿里巴巴李三红:目前阿里巴巴大部分的应用运行在 Dragonwell 8,有些已经运行在了 Dragonwell 11, 我们正在逐步推动从 Java8 到 Java11 的升级,充分享受技术红利。 美团吴革:美团现阶段主要使用 Java8,很少一部分是 Java7。部分核心团队正在尝试 Java 11。在美团内部采用的开发版本 JDK 主要还是 Oracle JDK。我们在服务器上的 JDK 版本主要是美团自己的 MtJDK 和 Oracle JDK。美团现阶段正在测试基于 OpenJDK 的 MtJDK,作为美团 JDK 基础服务。 MtJDK 主要基于 OpenJDK 构建,现阶段主要针对补丁和安全性进行维护。现阶段在特定业务线内部进行测试和应用。未来配合 Serverless 等基础服务升级,MtJDK 会在 JDK 启动性能和增强应用之间的隔离进行深度定制。 小米黄飞:小米主要使用 OpenJDK8 以及 11 版本。目前对 OpenJDK 主要还是以使用为主,主要的业务关注点在于这个版本是否为长期支持;是否有更加高效易用的特征,例如 GC 算法由 CMS、G1 升级到 ZGC 等;开源社区是否活跃;以及对遇到的问题是否有足够丰富的资料与讨论等。 Java 作为使用最为广泛的语言,最近几年还是有比较大进步的,无论从语法的易用性上还是性能上都有很大程度的提升。吸收了函数式编程的思想,lambda 表达式、Parallem stream、Var 变量等提升了开发人员的效率与代码的简洁性。ZGC 无疑是一项重大的改进,在一定程度上解决了 Java 天生的 GC 问题。

游客pklijor6gytpx 2019-12-02 03:11:37 0 浏览量 回答数 0

问题

如何在基于Python的Robot框架中包含Java测试库

祖安文状元 2020-02-23 16:35:13 0 浏览量 回答数 1

回答

我也遇见同样的问题,求解######研究了研究,这个问题算是解决了。这应该算一个BUG。结症就在这个方法中: private String getFileItemName(final FileItem item) { if (item.getName().lastIndexOf('/') != -1) {    return item.getName()      .substring(item.getName().lastIndexOf('/') + 1);   } else {    return item.getName();   } } 位于com.ckfinder.connector.handlers.command.FileUploadCommand.java中。 这是判断文件名的代码,IE中获取的文件名是有路径的,FF中直接是文件名。只需要把‘/’改为'\'。为避免中文问题,直接改文件名就好了,用UUID。 对了,在网上搜索CKfinder时,发现java的例子甚少。可能由于Ckfinder早期没有提供对java的支持,人们都改用kcfinder? 现在Ckfinder已经有java版了,大家可以下载研究使用。 最近在使用这个,有问题可以一起讨论。QQ:15432088######这个是收费的啊。。。

kun坤 2020-05-31 21:44:22 0 浏览量 回答数 0

回答

无论是注解还是其它形式的配置,例如xml,在 JFinal 中都会被尽可能地避免,注解也是配置的一种形式。COC 原则是比使用配置更加优秀的思想。 所以 JFinal 只需要使用 me.add("user", UserController.class) 这种方式即可将 UserController 中所有 action 进行路由配置,而不必对每个 action 使用冗余而繁琐的 RequestMapping 注解。 动态参数绑定到参数列表对于 java 语言来说不太合适,除了有性能方面的原因,更重要是语言方面的支持力度不够。例如:假定 public void action(String userName) 这个 action,传来了一个参数叫 String userName,对于框架实现来说,要得到 userName 这个参数所对应的值需要这样 reqeuest.getParameter("userName"),问题来了,对于java 语言来说无法得到 "userName" 这个字符串,也即你无法知道形参的参数名,只能知道它的参数类型,因为String userName 这个参数的名称会在编译后变成一个符号性的东西。 在 java 世界里,想要知道方法参数名称通常的做法是使用额外的注解,spring 是这样解决的:public void action(@Parameter(name="userName") String un),这种方式代码量提升了不利于极速开发。另一个得到参数名称的办法是通过类似于 eclipse 编译器 ecj 这样的东东,这种编译器在编译 java 代码时,将参数名称进行了保留没有符号化,但你需要写程序对编译后的 class 文件进行分析得到参数名称,这样不仅对性能十分不利而且一旦换了编译器就会失效,体验非常地差。eclipse 的 ecj 的目的是为了代码提示功能可以显示出参数名,也为了调试程序时可以显示参数名。语言层面还有一个纠结的问题,如果编译时保留参数名,那么反编译就变得更容易。 以上的讨论还没有涉及action method带参数后重载方法的问题,随着讨论的深入会发现复杂度会提升更多,而 jfinal 的解决方案是以上权衡后的结果,使用 getModel(...) 就可以搞定参数的绑定,代码量不仅极少,而且性能最优。如果将来 java 在语言层面对方法参数名有支持 jfinal 会立即考虑实现,作者所期望的形式类似于这样: Para p = method.getPara(int); String paraName = p.getName();

a123456678 2019-12-02 02:12:47 0 浏览量 回答数 0

回答

我也遇见同样的问题,求解###### 研究了研究,这个问题算是解决了。这应该算一个BUG。结症就在这个方法中: private String getFileItemName(final FileItem item) { if (item.getName().lastIndexOf('/') != -1) {    return item.getName()      .substring(item.getName().lastIndexOf('/') + 1);   } else {    return item.getName();   } } 位于com.ckfinder.connector.handlers.command.FileUploadCommand.java中。 这是判断文件名的代码,IE中获取的文件名是有路径的,FF中直接是文件名。只需要把‘/’改为'\\'。为避免中文问题,直接改文件名就好了,用UUID。 对了,在网上搜索CKfinder时,发现java的例子甚少。可能由于Ckfinder早期没有提供对java的支持,人们都改用kcfinder? 现在Ckfinder已经有java版了,大家可以下载研究使用。 最近在使用这个,有问题可以一起讨论。QQ:15432088######这个是收费的啊。。。

montos 2020-06-01 12:57:28 0 浏览量 回答数 0

回答

我也遇见同样的问题,求解###### 研究了研究,这个问题算是解决了。这应该算一个BUG。结症就在这个方法中: private String getFileItemName(final FileItem item) { if (item.getName().lastIndexOf('/') != -1) {    return item.getName()      .substring(item.getName().lastIndexOf('/') + 1);   } else {    return item.getName();   } } 位于com.ckfinder.connector.handlers.command.FileUploadCommand.java中。 这是判断文件名的代码,IE中获取的文件名是有路径的,FF中直接是文件名。只需要把‘/’改为'\\'。为避免中文问题,直接改文件名就好了,用UUID。 对了,在网上搜索CKfinder时,发现java的例子甚少。可能由于Ckfinder早期没有提供对java的支持,人们都改用kcfinder? 现在Ckfinder已经有java版了,大家可以下载研究使用。 最近在使用这个,有问题可以一起讨论。QQ:15432088######这个是收费的啊。。。

kun坤 2020-06-14 06:26:09 0 浏览量 回答数 0

问题

关于javaEE如何和node.js通信问题? 400 报错

爱吃鱼的程序员 2020-05-29 20:43:22 0 浏览量 回答数 1

问题

phper者的未来在哪里

白萝卜992 2019-12-01 19:54:37 838 浏览量 回答数 6

问题

【精品问答】Java技术1000问(1)

问问小秘 2019-12-01 21:57:43 35864 浏览量 回答数 11

回答

" <span style=""background-color:#ffffee;"">我也遇见同样的问题,求解###### 研究了研究,这个问题算是解决了。这应该算一个BUG。结症就在这个方法中: private String getFileItemName(final FileItem item) { if (item.getName().lastIndexOf('/') != -1) {    return item.getName()      .substring(item.getName().lastIndexOf('/') + 1);   } else {    return item.getName();   } } 位于com.ckfinder.connector.handlers.command.FileUploadCommand.java中。 这是判断文件名的代码,IE中获取的文件名是有路径的,FF中直接是文件名。只需要把‘/’改为'\\'。为避免中文问题,直接改文件名就好了,用UUID。 对了,在网上搜索CKfinder时,发现java的例子甚少。可能由于Ckfinder早期没有提供对java的支持,人们都改用kcfinder? 现在Ckfinder已经有java版了,大家可以下载研究使用。 最近在使用这个,有问题可以一起讨论。QQ:15432088######这个是收费的啊。。。 "

montos 2020-05-31 12:03:25 0 浏览量 回答数 0

问题

jfinal-ext 关于PoiRender导出excel但是无数据?报错

爱吃鱼的程序员 2020-06-10 11:00:00 0 浏览量 回答数 1

问题

Tomcat 中Session 管理的实现和细节疑问

落地花开啦 2019-12-01 19:32:41 954 浏览量 回答数 1

回答

小伙子,那你在学习一边。多写代码。多在阿里巴巴Java群里参与讨论问题。学习好了可以面试阿里巴巴 、蚂蚁金服等名企了。学以致用,不会忘记的。最新《阿里巴巴Java Spring Boot 2.0开发实战课程》持续更新 完全免费第1课:Spring Boot2.0新特性和入门实战,https://yq.aliyun.com/live/583 第2课:Spring Boot2.0开发MVC网站并显示图片,https://yq.aliyun.com/live/592第3课:Spring Boot2.0实战MySQL和3个高级面试题,https://yq.aliyun.com/live/612第4课:Spring Boot2.0实战MVC用户登录和注册和Java面试题https://yq.aliyun.com/live/644第5课:Spring Boot2.0实战三层MVC架构实战与架构分层误区(Java面试题)https://yq.aliyun.com/live/655第6课:Spring Boot2.0实战MyBatis与优化(Java面试题)https://yq.aliyun.com/live/687第7课:Spring Boot2.0安全机制、漏洞与MVC身份验证实战(Java面试题) https://yq.aliyun.com/live/712第8课:Spring Boot2.0自动化配置机制解析(Java面试题) 课件 PPT下载 https://yq.aliyun.com/live/729第9课:Spring Boot2.0实战MongoDB4.0(MongoDB面试题) https://yq.aliyun.com/live/782第10课:Spring Boot2.0实战高并发缓存Redis面试题) https://yq.aliyun.com/live/791第11课:Spring Boot2.0实战RabbitMQ中间件与API原理解析 https://yq.aliyun.com/live/806第12课:Spring Boot2.0性能监控实战与Actuator机制解析 https://yq.aliyun.com/live/815第13课:Spring Boot2.0性能监控实战ElasticSearch搜索引擎中间件 https://yq.aliyun.com/live/844最新《阿里巴巴Java Spring Boot 2.0开发实战课程》官方网站 完全免费第14课:Spring Boot 2.0实战MyBatis连接池阿里Druid与SQL性能监控

徐雷frank 2019-12-02 01:47:06 0 浏览量 回答数 0

问题

java异常的讨论问题:报错 

kun坤 2020-06-08 16:20:05 0 浏览量 回答数 1

问题

无法WrappedPreparedStatementJDK8转换为SQLServerPrepared

montos 2020-03-27 22:50:50 1 浏览量 回答数 1

问题

襄樊开诊断证明-ggc

游客5k2abgdj3m2ti 2019-12-01 22:08:58 3 浏览量 回答数 0

问题

十堰开诊断证明-lpt

游客5k2abgdj3m2ti 2019-12-01 22:08:56 3 浏览量 回答数 0

回答

我们都知道JVM的内存管理是自动化的,Java语言的程序指针也不需要开发人员手工释放,JVM的GC会自动的进行回收,但是,如果编程不当,JVM仍然会发生内存泄露,导致Java程序产生了OutOfMemoryError(OOM)错误。 产生OutOfMemoryError错误的原因包括: java.lang.OutOfMemoryError: Java heap spacejava.lang.OutOfMemoryError: PermGen space及其解决方法java.lang.OutOfMemoryError: unable to create new native threadjava.lang.OutOfMemoryError:GC overhead limit exceeded对于第1种异常,表示Java堆空间不够,当应用程序申请更多的内存,而Java堆内存已经无法满足应用程序对内存的需要,将抛出这种异常。 对于第2种异常,表示Java永久带(方法区)空间不够,永久带用于存放类的字节码和长常量池,类的字节码加载后存放在这个区域,这和存放对象实例的堆区是不同的,大多数JVM的实现都不会对永久带进行垃圾回收,因此,只要类加载的过多就会出现这个问题。一般的应用程序都不会产生这个错误,然而,对于Web服务器来讲,会产生有大量的JSP,JSP在运行时被动态的编译成Java Servlet类,然后加载到方法区,因此,太多的JSP的Web工程可能产生这个异常。 对于第3种异常,本质原因是创建了太多的线程,而能创建的线程数是有限制的,导致了这种异常的发生。 对于第4种异常,是在并行或者并发回收器在GC回收时间过长、超过98%的时间用来做GC并且回收了不到2%的堆内存,然后抛出这种异常进行提前预警,用来避免内存过小造成应用不能正常工作。 下面两个异常与OOM有关系,但是,又没有绝对关系。 java.lang.StackOverflowError ...java.net.SocketException: Too many open files对于第1种异常,是JVM的线程由于递归或者方法调用层次太多,占满了线程堆栈而导致的,线程堆栈默认大小为1M。 对于第2种异常,是由于系统对文件句柄的使用是有限制的,而某个应用程序使用的文件句柄超过了这个限制,就会导致这个问题。 上面介绍了OOM相关的基础知识,接下来我们开始讲述笔者经历的一次OOM问题的定位和解决的过程。 产生问题的现象 在某一段时间内,我们发现不同的业务服务开始偶发的报OOM的异常,有的时候是白天发生,有的时候是晚上发生,有的时候是基础服务A发生,有的时候是上层服务B发生,有的时候是上层服务C发生,有的时候是下层服务D发生,丝毫看不到一点规律。 产生问题的异常如下: Caused by: java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method)at java.lang.Thread.start(Thread.java:597)at java.util.Timer.(Timer.java:154) 解决问题的思路和过程 经过细心观察发现,产生问题虽然在不同的时间发生在不同的服务池,但是,晚上0点发生的时候概率较大,也有其他时间偶发,但是都在整点。 这个规律很重要,虽然不是一个时间,但是基本都在整点左右发生,并且晚上0点居多。从这个角度思考,整点或者0点系统是否有定时,与出问题的每个业务系统技术负责人核实,0点没有定时任务,其他时间的整点有定时任务,但是与发生问题的时间不吻合,这个思路行不通。 到现在为止,从现象的规律上我们已经没法继续分析下去了,那我们回顾一下错误本身: java.lang.OutOfMemoryError: unable to create new native thread 顾名思义,错误产生的原因就是应用不能创建线程了,但是,应用还需要创建线程。为什么程序不能创建线程呢? 有两个具体原因造成这个异常: 由于线程使用的资源过多,操作系统已经不能再提供给应用资源了。操作系统设置了应用创建线程的最大数量,并且已经达到了最大允许数量。上面第1条资源指的是内存,而第2条中,在Linux下线程使用轻量级进程实现的,因此线程的最大数量也是操作系统允许的进程的最大数量。 内存计算 操作系统中的最大可用内存除去操作系统本身使用的部分,剩下的都可以为某一个进程服务,在JVM进程中,内存又被分为堆、本地内存和栈等三大块,Java堆是JVM自动管理的内存,应用的对象的创建和销毁、类的装载等都发生在这里,本地内存是Java应用使用的一种特殊内存,JVM并不直接管理其生命周期,每个线程也会有一个栈,是用来存储线程工作过程中产生的方法局部变量、方法参数和返回值的,每个线程对应的栈的默认大小为1M。 Linux和JVM的内存管理示意图如下: 内存结构模型因此,从内存角度来看创建线程需要内存空间,如果JVM进程正当一个应用创建线程,而操作系统没有剩余的内存分配给此JVM进程,则会抛出问题中的OOM异常:unable to create new native thread。 如下公式可以用来从内存角度计算允许创建的最大线程数: 最大线程数 = (操作系统最大可用内存 - JVM内存 - 操作系统预留内存)/ 线程栈大小 根据这个公式,我们可以通过剩余内存计算可以创建线程的数量。 下面是问题出现的时候,从生产机器上执行前面小节介绍的Linux命令free的输出: free -m >> /tmp/free.log total used free shared buffers cached Mem: 7872 7163 709 0 31 3807-/+ buffers/cache: 3324 4547Swap: 4095 173 3922Tue Jul 5 00:27:51 CST 2016从上面输出可以得出,生产机器8G内存,使用了7G,剩余700M可用,其中操作系统cache使用3.8G。操作系统cache使用的3.8G是用来缓存IO数据的,如果进程内存不够用,这些内存是可以释放出来优先分配给进程使用。然而,我们暂时并不需要考虑这块内存,剩余的700M空间完全可以继续用来创建线程数: 700M / 1M = 700个线程 因此,根据内存可用计算,当OOM异常:unable to create new native thread问题发生的时候,还有700M可用内存,可以创建700个线程。 到现在为止可以证明此次OOM异常不是因为线程吃光所有的内存而导致的。 线程数对比 上面提到,有两个具体原因造成这个异常,我们上面已经排除了第1个原因,那我们现在从第2个原因入手,评估是否操作系统设置了应用创建线程的最大数量,并且已经达到了最大允许数量。 在问题出现的生产机器上使用ulimit -a来显示当前的各种系统对用户使用资源的限制: robert@robert-ubuntu1410:~$ ulimit -acore file size (blocks, -c) 0data seg size (kbytes, -d) unlimitedscheduling priority (-e) 0file size (blocks, -f) unlimitedpending signals (-i) 62819max locked memory (kbytes, -l) 64max memory size (kbytes, -m) unlimitedopen files (-n) 65535pipe size (512 bytes, -p) 8POSIX message queues (bytes, -q) 819200real-time priority (-r) 0stack size (kbytes, -s) 10240cpu time (seconds, -t) unlimitedmax user processes (-u) 1024virtual memory (kbytes, -v) unlimitedfile locks (-x) unlimited这里面我们看到生产机器设置的允许使用的最大用户进程数为1024: max user processes (-u) 1024现在,我们必须获得问题出现的时候,用户下创建的线程情况。 在问题产生的时候,我们使用前面小结介绍的JVM监控命令jstack命令打印出了Java线程情况,jstack命令的示例输出如下: robert@robert-ubuntu1410:~$ jstack 27432017-04-09 12:06:51Full thread dump Java HotSpot(TM) Server VM (25.20-b23 mixed mode): "Attach Listener" #23 daemon prio=9 os_prio=0 tid=0xc09adc00 nid=0xb4c waiting on condition [0x00000000] java.lang.Thread.State: RUNNABLE "http-nio-8080-Acceptor-0" #22 daemon prio=5 os_prio=0 tid=0xc3341000 nid=0xb02 runnable [0xbf1bd000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method) at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:241) - locked <0xcf8938d8> (a java.lang.Object) at org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:688) at java.lang.Thread.run(Thread.java:745) "http-nio-8080-ClientPoller-1" #21 daemon prio=5 os_prio=0 tid=0xc35bc400 nid=0xb01 runnable [0xbf1fe000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) - locked <0xcf99b100> (a sun.nio.ch.Util$2) - locked <0xcf99b0f0> (a java.util.Collections$UnmodifiableSet) - locked <0xcf99aff8> (a sun.nio.ch.EPollSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) at org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1052) at java.lang.Thread.run(Thread.java:745) ......从jstack命令的输出并统计后,我们得知,JVM一共创建了904个线程,但是,这还没有到最大的进程限制1024。 robert@robert-ubuntu1410:~$ grep "Thread " js.log | wc -l 904 这是我们思考,除了JVM创建的应用层线程,JVM本身可能会有一些管理线程存在,而且操作系统内用户下可能也会有守护线程在运行。 我们继续从操作系统的角度来统计线程数,我们使用上面小结介绍的Linux操作系统命令pstack,并得到如下的输出: PID LWP USER %CPU %MEM CMD 1 1 root 0.0 0.0 /sbin/init 2 2 root 0.0 0.0 [kthreadd] 3 3 root 0.0 0.0 [migration/0] 4 4 root 0.0 0.0 [ksoftirqd/0] 5 5 root 0.0 0.0 [migration/0] 6 6 root 0.0 0.0 [watchdog/0] 7 7 root 0.0 0.0 [migration/1] 8 8 root 0.0 0.0 [migration/1] 9 9 root 0.0 0.0 [ksoftirqd/1] 10 10 root 0.0 0.0 [watchdog/1] 11 11 root 0.0 0.0 [migration/2] 12 12 root 0.0 0.0 [migration/2] 13 13 root 0.0 0.0 [ksoftirqd/2] 14 14 root 0.0 0.0 [watchdog/2] 15 15 root 0.0 0.0 [migration/3] 16 16 root 0.0 0.0 [migration/3] 17 17 root 0.0 0.0 [ksoftirqd/3] 18 18 root 0.0 0.0 [watchdog/3] 19 19 root 0.0 0.0 [events/0] 20 20 root 0.0 0.0 [events/1] 21 21 root 0.0 0.0 [events/2] 22 22 root 0.0 0.0 [events/3] 23 23 root 0.0 0.0 [cgroup] 24 24 root 0.0 0.0 [khelper] ...... 7257 7257 zabbix 0.0 0.0 /usr/local/zabbix/sbin/zabbix_agentd: active checks #2 [idle 1 sec] 7258 7258 zabbix 0.0 0.0 /usr/local/zabbix/sbin/zabbix_agentd: active checks #3 [idle 1 sec] 7259 7259 zabbix 0.0 0.0 /usr/local/zabbix/sbin/zabbix_agentd: active checks #4 [idle 1 sec] ...... 9040 9040 app 0.0 30.5 /apps/prod/jdk1.6.0_24/bin/java -Dnop -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Ddbconfigpath=/apps/dbconfig/ -Djava.io.tmpdir=/apps/data/java-tmpdir -server -Xms2048m -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=512m -Dcom.sun.management.jmxremote -Djava.rmi.server.hostname=192.168.10.194 -Dcom.sun.management.jmxremote.port=6969 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Xshare:off -Dhostname=sjsa-trade04 -Djute.maxbuffer=41943040 -Djava.net.preferIPv4Stack=true -Dfile.encoding=UTF-8 -Dworkdir=/apps/data/tomcat-work -Djava.endorsed.dirs=/apps/product/tomcat-trade/endorsed -classpath commonlib:/apps/product/tomcat-trade/bin/bootstrap.jar:/apps/product/tomcat-trade/bin/tomcat-juli.jar -Dcatalina.base=/apps/product/tomcat-trade -Dcatalina.home=/apps/product/tomcat-trade -Djava.io.tmpdir=/apps/data/tomcat-temp/ org.apache.catalina.startup.Bootstrap start 9040 9041 app 0.0 30.5 /apps/prod/jdk1.6.0_24/bin/java -Dnop -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Ddbconfigpath=/apps/dbconfig/ -Djava.io.tmpdir=/apps/data/java-tmpdir -server -Xms2048m -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=512m -Dcom.sun.management.jmxremote -Djava.rmi.server.hostname=192.168.10.194 -Dcom.sun.management.jmxremote.port=6969 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Xshare:off -Dhostname=sjsa-trade04 -Djute.maxbuffer=41943040 -Djava.net.preferIPv4Stack=true -Dfile.encoding=UTF-8 -Dworkdir=/apps/data/tomcat-work -Djava.endorsed.dirs=/apps/product/tomcat-trade/endorsed -classpath commonlib:/apps/product/tomcat-trade/bin/bootstrap.jar:/apps/product/tomcat-trade/bin/tomcat-juli.jar -Dcatalina.base=/apps/product/tomcat-trade -Dcatalina.home=/apps/product/tomcat-trade -Djava.io.tmpdir=/apps/data/tomcat-temp/ org.apache.catalina.startup.Bootstrap start ......通过命令统计用户下已经创建的线程数为1021。 $ grep app pthreads.log | wc -l 1021 现在我们确定,1021的数字已经相当的接近1021的最大进程数了,正如前面我们提到,在Linux操作系统里,线程是通过轻量级的进程实现的,因此,限制用户的最大进程数,就是限制用户的最大线程数,至于为什么没有精确达到1024这个最大值就已经报出异常,应该是系统的自我保护功能,在还剩下3个线程的前提下,就开始报错。 到此为止,我们已经通过分析来找到问题的原因,但是,我们还是不知道为什么会创建这么多的线程,从第一个输出得知,JVM已经创建的应用线程有907个,那么他们都在做什么事情呢? 于是,在问题发生的时候,我们又使用JVM的jstack命令,查看输出得知,每个线程都阻塞在打印日志的语句上,log4j中打印日志的代码实现如下: public void callAppenders(LoggingEvent event) { int writes = 0; for(Category c = this; c != null; c=c.parent) { // Protected against simultaneous call to addAppender, removeAppender,... synchronized(c) { if(c.aai != null) { writes += c.aai.appendLoopOnAppenders(event); } if(!c.additive) { break; } } } if(writes == 0) { repository.emitNoAppenderWarning(this); } }在log4j中,打印日志有一个锁,锁的作用是让打印日志可以串行,保证日志在日志文件中的正确性和顺序性。 那么,新的问题又来了,为什么只有凌晨0点会出现打印日志阻塞,其他时间会偶尔发生呢?这时,我们带着新的线索又回到问题开始的思路,凌晨12点应用没有定时任务,系统会不会有其他的IO密集型的任务,比如说归档日志、磁盘备份等? 经过与运维部门碰头,基本确定是每天凌晨0点日志切割导致磁盘IO被占用,于是堵塞打印日志,日志是每个工作任务都必须的,日志阻塞,线程池就阻塞,线程池阻塞就导致线程池被撑大,线程池里面的线程数超过1024就会报错。 到这里,我们基本确定了问题的原因,但是还需要对日志切割导致IO增大进行分析和论证。 首先我们使用前面小结介绍的vmstat查看问题发生时IO等待数据: vmstat 2 1 >> /tmp/vm.logprocs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 3 0 177608 725636 31856 3899144 0 0 2 10 0 0 39 1 1 59 0 Tue Jul 5 00:27:51 CST 2016可见,问题发生的时候,CPU的IO等待为59%,同时又与运维部门同事复盘,运维同事确认,脚本切割通过cat命令方法,先把日志文件cat后,通过管道打印到另外一个文件,再清空原文件,因此,一定会导致IO的上升。 其实,问题的过程中,还有一个疑惑,我们认为线程被IO阻塞,线程池被撑开,导致线程增多,于是,我们查看了一下Tomcat线程池的设置,我们发现Tomcat线程池设置了800,按理说,永远不会超过1024。 maxThreads="800" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8443" acceptCount="100" debug="0" connectionTimeout="20000" disableUploadTimeout="true" /> 关键在于,笔者所在的支付平台服务化架构中,使用了两套服务化框架,一个是基于dubbo的框架,一个是点对点的RPC,用来紧急情况下dubbo服务出现问题,服务降级使用。 每个服务都配置了点对点的RPC服务,并且独享一个线程池: maxThreads="800" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8443" acceptCount="100" debug="0" connectionTimeout="20000" disableUploadTimeout="true" /> 由于我们在对dubbo服务框架进行定制化的时候,设计了自动降级原则,如果dubbo服务负载变高,会自动切换到点对点的RPC框架,这也符合微服务的失效转移原则,但是设计中没有进行全面的考虑,一旦一部分服务切换到了点对点的RPC,而一部分的服务没有切换,就导致两个现场池都被撑满,于是超过了1024的限制,就出了问题。 到这里,我们基本可以验证,问题的根源是日志切割导致IO负载增加,然后阻塞线程池,最后发生OOM:unable to create new native thread。 剩下的任务就是最小化重现的问题,通过实践来验证问题的原因。我们与性能压测部门沟通,提出压测需求: Tomcat线程池最大设置为1500.操作系统允许的最大用户进程数1024.在给服务加压的过程中,需要人工制造繁忙的IO操作,IO等待不得低于50%。经过压测压测部门的一下午努力,环境搞定,结果证明完全可以重现此问题。 最后,与所有相关部门讨论和复盘,应用解决方案,解决方案包括: 全部应用改成按照小时切割,或者直接使用log4j的日志滚动功能。Tomcat线程池的线程数设置与操作系统的线程数设置不合理,适当的减少Tomcat线程池线程数量的大小。升级log4j日志,使用logback或者log4j2。这次OOM问题的可以归结为“多个因、多个果、多台机器、多个服务池、不同时间”,针对这个问题,与运维部、监控部和性能压测部门的同事奋斗了几天几夜,终于通过在线上抓取信息、分析问题、在性能压测部门同事的帮助下,最小化重现问题并找到问题的根源原因,最后,针对问题产生的根源提供了有效的方案。 与监控同事现场编写的脚本 本节提供一个笔者在实践过程中解决OOM问题的一个简单脚本,这个脚本是为了解决OOM(unable to create native thread)的问题而在问题机器上临时编写,并临时使用的,脚本并没有写的很专业,笔者也没有进行优化,保持原汁原味的风格,这样能让读者有种身临其境的感觉,只是为了抓取需要的信息并解决问题,但是在线上问题十分火急的情况下,这个脚本会有大用处。 !/bin/bash ps -Leo pid,lwp,user,pcpu,pmem,cmd >> /tmp/pthreads.logecho "ps -Leo pid,lwp,user,pcpu,pmem,cmd >> /tmp/pthreads.log" >> /tmp/pthreads.logecho date >> /tmp/pthreads.logecho 1 pid=ps aux|grep tomcat|grep cwh|awk -F ' ' '{print $2}'echo 2 echo "pstack $pid >> /tmp/pstack.log" >> /tmp/pstack.logpstack $pid >> /tmp/pstack.logecho date >> /tmp/pstack.logecho 3 echo "lsof >> /tmp/sys-o-files.log" >> /tmp/sys-o-files.loglsof >> /tmp/sys-o-files.logecho date >> /tmp/sys-o-files.logecho 4 echo "lsof -p $pid >> /tmp/service-o-files.log" >> /tmp/service-o-files.loglsof -p $pid >> /tmp/service-o-files.logecho date >> /tmp/service-o-files.logecho 5 echo "jstack -l $pid >> /tmp/js.log" >> /tmp/js.logjstack -l -F $pid >> /tmp/js.logecho date >> /tmp/js.logecho 6 echo "free -m >> /tmp/free.log" >> /tmp/free.logfree -m >> /tmp/free.logecho date >> /tmp/free.logecho 7 echo "vmstat 2 1 >> /tmp/vm.log" >> /tmp/vm.logvmstat 2 1 >> /tmp/vm.logecho date >> /tmp/vm.logecho 8 echo "jmap -dump:format=b,file=/tmp/heap.hprof 2743" >> /tmp/jmap.logjmap -dump:format=b,file=/tmp/heap.hprof >> /tmp/jmap.logecho date >> /tmp/jmap.logecho 9 echo end

hiekay 2019-12-02 01:39:43 0 浏览量 回答数 0

问题

鄂州开诊断证明-asa

游客5k2abgdj3m2ti 2019-12-01 22:08:58 3 浏览量 回答数 0

问题

驻马店开诊断证明-feu

游客5k2abgdj3m2ti 2019-12-01 22:08:55 3 浏览量 回答数 0

问题

荆门开诊断证明-scc

游客5k2abgdj3m2ti 2019-12-01 22:08:59 3 浏览量 回答数 0

问题

黄石开诊断证明-kku

游客5k2abgdj3m2ti 2019-12-01 22:08:55 3 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 云栖号物联网 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站 云栖号弹性计算 阿里云云栖号 云栖号案例 云栖号直播