会不会工作一两年了 还没用到过 jvm 调优 而是由 DevOpt 或者部署工程师去做？
This topic created in 3601 days ago, the information mentioned may be changed or developed.
 |
1
性能不够时应用做负载均衡，数据做主从，然后项目就死了，不会再优化了………
|
1 |
sagaxuDec 25, 2016 via Android
2
也就调个内存大小和 gc 参数，其它都默认
|
 |
xiamxDec 26, 2016
3
Devops
|
 |
slixurdDec 26, 2016
4
至少会调个堆大小吧....
|
 |
wmhxDec 26, 2016
5
国内需要天天优化 jvm 的就那么几个公司,
大把小公司活都干不完, 那里有空玩什么 jvm , 现在硬件这么便宜, 多加点内存,跑几个 jvm 不比往死里优化 jvm 来的快么? |
 |
yuhuan66666Dec 26, 2016 via Android
6
Java 面试总被问到的问题。。。。
但是实际从来基本没动过，顶多改改堆大小啥的 |
 |
q397064399Dec 26, 2016
7
过早优化是万恶之源，能跑得动，或者加硬件能解决的 ，尽量不要用人力去解决，
现在硬件老便宜了，实在不行就上云服务器，再不行，就做负载均衡， nginx 反代，多个 tomcat 共享 session 池，然后数据库 做读写分离，最后还不行的话， 这项目也就差不多死透了，要么交个大公司做，要么就扩大团队，招一堆 架构师来 :D |
|
q397064399Dec 26, 2016
8
首先优化这事情，肯定不是运维部署这些人能干的，否则还要程序员干嘛?
你给它写个 O （ N3 ）的算法在哪里跑，顺带还把数据库的连接池给耗空了，业务量一上来， 运维再怎么优化 也只能干瞪眼啊 例如把 select xxx from tablexx where x in (xxxx)这样的业务逻辑 用 Java 代码写出来，把整张表读出来，然后给它 朴素排序一遍，再根据用户提交查找并集， 顺带给整张表做事务最高级别处理，整表加锁 |
|
q397064399Dec 26, 2016
9
我也读过一部分深入理解 JVM 虚拟机，不过 JVM 的实现，我们肯定是很难搞懂的，
但是大概了解下 GC ROOTS 方式之类还是可以的。 从实际出发，真正对 GC 延迟要求极高的系统，实际上并不适合 Java 来做， stop the world （一般都是 C++，手动管理内存，这样的系统实时性才高，例如 股票金融系统的实时性 ） 无论你再怎么调优， JVM 的 GC 算法是虚拟机厂商的黑盒，它是不会让你碰的， 而绝大部分做 Java 需要调优的场景相当少， 极高性能需求的 肯定是 C/C++， 这些语言的开发者在有必要的时候，连内存管理器都是自己定制的 （例如 redis ，它的底层实现是 hashmap ，很多数据结构都是通过自定义内存管理器实现的） （ Java 门槛一看就低多了，根本没办法定制内存管理器） 对实时性有一定的要求，也有 Java 市场，但是不多，绝大部分开发领域的 Java 开发者接触不到而已， |
|
q397064399Dec 26, 2016
10
主流虚拟机根据书上的介绍描述是，
没有任何一个 JVM 的 GC 实现 可以避免 stop the world |
 |
InfernalzeroDec 26, 2016
11
数据库调优肯定得懂的啊，这你也让运维搞？
|
 |
ljcarsenalDec 26, 2016
12
jvm 不是吊打一票动态语言的 vm
|
|
InfernalzeroDec 26, 2016
13
@q397064399 哥....整张表读出来，这表一大，分分钟给你搞跪啊，人查询都限制返回行数的，普通 IN 查询根本没有问题，只要不是条件参数太多
|
 |
zacardDec 26, 2016
14
数据库调优不可避免吧，索引合理性， sql 合理性等等。 jvm 调整的比较少，但是也有。
|
|
q397064399Dec 26, 2016
15
@Infernalzero 我只是假设而已，全读出来 肯定跪了，这种情况 查询并集的情况 肯定是要用 sql 来完成的
sql 存储引擎后面的算法 比我的 O （ N2 ）肯定强啊 |
 |
janxinDec 26, 2016 via iPhone
16
一般情况下你用个脚本语言性能都可以，性能不够时应用做负载均衡，数据做主从，然后就行了。 XD
|
 |
xiuc001Dec 26, 2016
17
大多数是等不到调优项目就挂了
|
 |
XhstormRDec 26, 2016 via Android
18
也是哦。
|
 |
0915240Dec 26, 2016 via iPhone
19
@q397064399 这个是 过早优化是万恶之源
|
 |
ihuotuiDec 26, 2016
20
有， jvm 调优， sql 调优（比较少，在设计时候已经充分考虑好业务了），还有查看线程运行情况。
|
 |
neoblackcapDec 26, 2016
21
@q397064399 其实 GC 的实现还是相当公开的， openjdk 里面各种各样的 GC 都有算法论文，以及代码都是公开的，想怎么调就怎么调。
还有一个就是 stop the world 其实也是可以避免的， http://www.azulsystems.com/sites/default/files/images/c4_paper_acm.pdf 这篇论文就有说 azul 是如何实现一个 GC ，并将卡顿控制在 10ms 之内，也有金融公司用了他们 JVM 。 |
|
q397064399Dec 26, 2016
22
@neoblackcap 我不是很清楚，我读过一个章节，
深入理解 JVM 虚拟机 确实有一个章节 有讲过 能够避免 stop the world 的虚拟机 但是 GC 算法是如何实现我的就不清楚了？ GCROOTS 难道是 dfs 搜索 有向图？从堆栈模型来讲，所有的对象确实是形成了一个 有向闭环图 |
 |
eightqueenDec 26, 2016
23
java 还是太弱，需要优化内存，你看 php 就不用。
|
 |
kylefengDec 26, 2016
24
业务量不够，大部分情况下用不到。。。
|
 |
cjyang1128Dec 26, 2016
25
jvm 调优，看要怎么细致地调优了，太细致的话，人力成本就上去了，所以一般就调个堆栈内存和 gc 的一些参数，通过加机器能够解决的还是通过加机器解决好了。数据库调优，如果是 sql 层的调优，很简单，收益大，值得一做，数据库配置上的，没做过，不懂
|
 |
oa414Dec 26, 2016
26
换工作面试的时候...
开发的时候，做应用层很少碰到数据库“调优”，更多时候只是按照正确的方法去做或者去改，比如把查询写对而不是一堆 N ＋ 1 Query ，加正确合适的索引，把一些复杂统计操作从应用层迁移到数据库层实现。 |
 |
27
@q397064399 这年头有认(na)真(qian)做的 GC 基本都有避免 stop-the-world 的方法，有的能做到 incremental （把暂停分割成一点点一点点），有的能做到 concurrent （几乎不需要暂停），没有 bug 的状况下这些 GC 暂停时间肯定不是随着堆大小 O(n) 的，做得好基本都控制在几十或者几 ms 内……当然这个是有代价的，一般相比起完全的 stop-the-world 回收都会有一定的滞后，换句话说就是牺牲了 GC 的吞吐量（ thoroughput ）来换取低延时（ latency ）……
另外这些 GC 大部分就算不开源起码也会发发论文的……不至于黑盒子…… |
|
joyeeDec 27, 2016
29
@q397064399 至于怎么避免 stop-the-world ，最流行的就是各种 barrier + safepoint 检查来为 incremental / concurrent GC 提供保障了……有的是 read barrier 有的是 write barrier 有的都用（楼上的 azul 论文就都用），只要能想办法保证回收的时候不碰活的内存就行……
|
 |
skywaymanDec 27, 2016
31
jvm 调优少,内存调整首当其冲...
数据库调优是时时刻刻,因为一句 SQL 就能把数据库搞完蛋... |
 |
GimlyuDec 29, 2016
33
作为一个 Javaer ，都应该懂得这些，基本技能。 另外，谁来做这个事情，显得不重要了，重要的是有人做。做了的要比不做的收获多。。。这是个 “ You can you up ” 的时代。
|
 |
clearbugDec 31, 2016
34
看了几章《深入理解 Java 虚拟机》，然后是一头雾水。。感觉根本就不是我这种还未入门的小白该看的
|
Select Language