jvm性能调优都做了什么
JVM性能调优有很多设置,这个参考JVM参数即可.
主要调优的目的:
控制GC的行为.GC是一个后台处理,但是它也是会消耗系统性能的,因此经常会根据系统运行的程序的特性来更改GC行为
控制JVM堆栈大小.一般来说,JVM在内存分配上不需要你修改,(举例)但是当你的程序新生代对象在某个时间段产生的比较多的时候,就需要控制新生代的堆大小.同时,还要需要控制总的JVM大小避免内存溢出
控制JVM线程的内存分配.如果是多线程程序,产生线程和线程运行所消耗的内存也是可以控制的,需要通过一定时间的观测后,配置最优结果
Linux里面JVM内存怎么设置？
一、堆内存相关配置
设置堆初始值
指令1：-Xms2g
指令2：-XX:InitialHeapSize=2048m
设置堆区最大值
指令1：`-Xmx2g`
指令2： -XX:MaxHeapSize=2048m
缩小堆内存的时机
-XX:MaxHeapFreeRatio=70//堆内存使用率大于70时扩张堆内存，xms=xmx时该参数无效，默认值70
扩张堆内存的时机
-XX:MinHeapFreeRatio=40//堆内存使用率小于40时缩减堆内存，xms=xmx时该参数无效，默认值40
新生代内存配置
指令1：-Xmn512m
指令2：-XX:MaxNewSize=512m
2个survivor区和Eden区大小比率
指令：-XX:SurvivorRatio=6 //S区和Eden区占新生代比率为1:6,两个S区2:6
新生代和老年代的占比
-XX:NewRatio=4 //表示新生代:老年代 = 1:4 即老年代占整个堆的4/5；默认值=2
二、方法区内存配置常用参数
初始化的Metaspace大小，
-XX:MetaspaceSize ：
Metaspace最大值
-XX:MaxMetaspaceSize
三、线程栈内存配置常用参数
每个线程栈最大值
指令1：-Xss256k
指令2：-XX:ThreadStackSize=256k
注意：
栈设置太大，会导致线程创建减少。
栈设置小，会导致深入不够，深度的递归会导致栈溢出。
建议栈深度设置在3000-5000
四、配置垃圾收集器
Serial垃圾收集器（新生代）
开启：-XX:+UseSerialGC
关闭：-XX:-UseSerialGC
//新生代使用Serial 老年代则使用SerialOld
ParNew垃圾收集器（新生代）
开启 -XX:+UseParNewGC
关闭 -XX:-UseParNewGC
//新生代使用功能ParNew 老年代则使用功能CMS
Parallel Scavenge收集器（新生代）
开启 -XX:+UseParallelOldGC
关闭 -XX:-UseParallelOldGC
//新生代使用功能Parallel Scavenge 老年代将会使用Parallel Old收集器
ParallelOl垃圾收集器（老年代）
开启 -XX:+UseParallelGC
关闭 -XX:-UseParallelGC
//新生代使用功能Parallel Scavenge 老年代将会使用Parallel Old收集器
CMS垃圾收集器（老年代）
开启 -XX:+UseConcMarkSweepGC
关闭 -XX:-UseConcMarkSweepGC
G1垃圾收集器
开启 -XX:+UseG1GC
关闭 -XX:-UseG1GC
五、GC策略配置
GC并行执行线程数
-XX:ParallelGCThreads=16
新生代可容纳的最大对象
-XX:PretenureSizeThreshold=1000000 //大于此值的对象直接会分配到老年代，设置为0则没有限制。 //避免在Eden区和Survivor区发生大量的内存复制，该参数只对Serial和ParNew收集器有效，Parallel Scavenge并不认识该参数
进入老年代的GC年龄
进入老年代最小的GC年龄
-XX:InitialTenuringThreshol=7 //年轻代对象转换为老年代对象最小年龄值，默认值7，对象在坚持过一次Minor GC之后，年龄就加1，每个对象在坚持过一次Minor GC之后，年龄就增加1
进入老年代最大的GC年龄
-XX:MaxTenuringThreshold=15 //年轻代对象转换为老年代对象最大年龄值，默认值15
六、GC日志信息配置
配置GC文件路径
-Xloggc:/data/gclog/gc.log//固定路径名称生成 -Xloggc:/home/GCEASY/gc-%t.log //根据时间生成
滚动生成日志
日志文件达到一定大小后，生成另一个文件。须配置Xloggc
开启 -XX:+UseGCLogFileRotation
关闭 -XX:-UseGCLogFileRotation
-XX:NumberOfGCLogFiles=4 //滚动GC日志文件数，默认0，不滚动 -XX:GCLogFileSize=100k //GC文件滚动大小，需配置UseGCLogFileRotation，设置为0表示仅通过jcmd命令触发
java栈内存溢出怎么产生
不只是Java而已。所有编程语言都会产生包子的问题。默认栈大小为2M，如果栈中的临时对象过多或者是过大就会爆栈
如何从根本上防止 SQL 注入
SQL注入并不是一个在SQL内不可解决的问题，这种攻击方式的存在也不能完全归咎于SQL这种语言，因为注入的问题而放弃SQL这种方式也是因噎废食。首先先说一个我在其他回答中也曾提到过的观点：没有（运行时）编译，就没有注入。
SQL注入产生的原因，和栈溢出、XSS等很多其他的攻击方法类似，就是未经检查或者未经充分检查的用户输入数据，意外变成了代码被执行。针对于SQL注入，则是用户提交的数据，被数据库系统编译而产生了开发者预期之外的动作。也就是，SQL注入是用户输入的数据，在拼接SQL语句的过程中，超越了数据本身，成为了SQL语句查询逻辑的一部分，然后这样被拼接出来的SQL语句被数据库执行，产生了开发者预期之外的动作。
所以从根本上防止上述类型攻击的手段，还是避免数据变成代码被执行，时刻分清代码和数据的界限。而具体到SQL注入来说，被执行的恶意代码是通过数据库的SQL解释引擎编译得到的，所以只要避免用户输入的数据被数据库系统编译就可以了。
现在的数据库系统都提供SQL语句的预编译（prepare）和查询参数绑定功能，在SQL语句中放置占位符'?'，然后将带有占位符的SQL语句传给数据库编译，执行的时候才将用户输入的数据作为执行的参数传给用户。这样的操作不仅使得SQL语句在书写的时候不再需要拼接，看起来也更直接，而且用户输入的数据也没有机会被送到数据库的SQL解释器被编译执行，也不会越权变成代码。
至于为什么这种参数化的查询方式没有作为默认的使用方式，我想除了兼容老系统以外，直接使用SQL确实方便并且也有确定的使用场合。
多说一点，从代码的角度来看，拼接SQL语句的做法也是不恰当的。
请教C语言高手一个栈溢出问题~
分配的变量char
c;是字符型，但输入的是%s字符串，这里会导致溢出。
WAS 中JAVA内存溢出的问题应该按照什么思路来解决？
�故荖ative thread无法创建，前者用MaxPermSize调整（IBM JDK没这个参数），后者调小最大堆大小或者Xss调整每个线程分配内存的大小。 如果是常见的堆的溢出，确保OutOfMemory时能生成heapdump文件，用Dump analyzer或者MDD4J分析dump文件，找到堆中占用空间总数最大的（或者数量最多的）对象。然后调整堆范围到一个比较小的区间，比如256M～384M，重新启动服务器，在运行1小时候手动做一次heapdump，运行4小时后做一次heapdump，运行8小时候做一次（间隔仅作参考）。然后分析一下三者的区别，看看哪个对象数量增长很多，占用空间增加很大。结合OutOfMemory时候的分析，应该能锁定问题的源头。 huweihong: 内存溢出是使用WAS时会经常遇到的问题。 1.现在WAS的控制台上打开详细垃圾回收。一旦出现OOM的错误时，会在nativeerr.log中有记录，也可以从这个日志中看出内存分配的情况。 2。参见hashei的回帖 把相关日志收集齐，使用ISA中的相关工具进行日志分析，会看到一些提示的。 有的时候内存溢出是WAS自身引入的，可以看看是不是有相关的补丁包。 还有多数都是自己开发程序的问题，使用的对象没有释放。这个就要具体情况具体分析了。 其实解决所有的问题的思路就是：大胆假设，小心求证。我的经验。：） 呵呵，其实我感觉95%以上的OOM发生都是和代码本身的质量有关系的， 以下是我的一点小思路,不知道对大家是否有帮助: OOM的情况,必定会产生宕机日志,所以,首先从分析宕机日志开始. 分析工具很多,根据侧重点不同进行选取即可. 一般情况下无非就是两重情况:大对象和内存泄露. 于是,赶紧查查业务代码,是那些地方产生的. 一个好的框架会帮你节省不少体力活的. 不过我感觉一般的大对象大都是RS引起的,不小心查了几万行数据又不做分页,不宕机都不行啊。
C语言超大数运算中栈溢出的问题……
char ta[4500],tb[4500],op,temp[9]; //ta临时储存a，tb临时储存b
这句temp[9]改为temp[10] ，9个保存读出的值，还有一个要放’\0'
这里下标越界好多，那个提示不是栈溢出的，是你访问下标越界了，
for(i=0;i=1001;i++){c[i]=pre;} 这里还有个也是越界了，应该到1000
做了一个测试，解释下为什么会Exception in thread "main" java.lang.StackOverflowError
你好，这个是正常的情况，递归时会把每次的方法调用存在堆栈中
你有两种解决方法，一是调整jvm的内存大小，二是把递归的方法改为循环迭代
所以一般写代码能避免递归就不要使用递归，递归其实是一种低效的但逻辑有时很清晰的策略