越深入java 就觉得java做得越烂(1.5,1.6的cache设计解决不了根本有关问题) 有关问题四 [Java][J2SE / 基础类]

越深入java 就觉得java做得越烂(1.5,1.6的cache设计解决不了根本问题) 问题四 [Java][J2SE / 基础类]
在前面三贴中，我提到过
1 Object 要用8byte指针内存
  see (http://topic.csdn.net/u/20081202/14/e93bd51a-a222-4e00-a7a5-5c6f07e7ed52.html)

2 Long a = 2l; 
Long b = 2l; 
//结果为ture 
System.out.println(a == b); 
Long c = 128l; 
Long d = 128l; 
//结果为false 
System.out.println(c == d);
  see (http://topic.csdn.net/u/20081119/12/b3c447ef-6665-4225-8d36-60e211663bb3.html)

3 JVM会把系统里的字符串常量，缓存到JVM中(在java中如果你定义N多个字符变量，值是一样的，实际在JVM中只有一份)

上面3个问题合起来可以说明一个问题：
java对基础数据的cache封装方案是不正确的，应当只能算是曲线救国，解决不了根本问题。
因原很简单：java应当cache 字符，而不是这符串String，
最好的选择是：cache utf-16le(java用的内部字符编码)，而java确不是这样做的。
导致的问题：a)符串String 常量是无法确定的，如果在一个系统中使用过多的常量，会让内存涨破。
  b)不能在for等语句中使用String，这样容易让内存out，系统玩完，(往往刚学的新手不知道)。
  c)逼得大家选择Stringbuffer类来操作可变String，很不方便。

问题核心提示：java 不cache utf-16le的愿因 是代价比cache String要高。为什么要高呢? 请详细了解 三个问题就可以回答。


[解决办法]
bd
[解决办法]
关注中……
[解决办法]
不咋懂，学习……
[解决办法]

[解决办法]
挨个看看......
[解决办法]
不懂，看看。
[解决办法]
搞java也三年了
觉得java最大的弱点是
在控制底层硬件上面太弱了
我也迷惘是不是自己走错方向了
[解决办法]
mark
[解决办法]
从来就不觉得Java做得不烂
软件慢，JRE各种版本冲突，语法e心
[解决办法]
为lz的执着顶一下
[解决办法]
看到各位达人的回帖。。。
是不是JAVA有天生的弊病？

[解决办法]
觉得java最大的弱点是 
在控制底层硬件上面太弱了 

[解决办法]
这一次不太同意楼主的看法

a)符串String 常量是无法确定的，如果在一个系统中使用过多的常量，会让内存涨破。 
字符串常量是硬编码到程序里的，目前再大的系统，编译之后生成的class最多几十M了不起了，估计其中的字符串常量也不会超过10%左右，这对一台服务器来说算不了什么。


b)不能在for等语句中使用String，这样容易让内存out，系统玩完，(往往刚学的新手不知道)。 
c)逼得大家选择Stringbuffer类来操作可变String，很不方便。 
我认为这两点都还好，现在的dot net在字符串操处理方式上和java也是类似的

[解决办法]
关注ing
[解决办法]
up
[解决办法]
ding

[解决办法]
每天进步一点点
[解决办法]
友情up
[解决办法]
友情up
[解决办法]
String作为基础的类，弄成final也是没办法的事情，一是出于效率，二是出于安全性。

b)不能在for等语句中使用String，这样容易让内存out，系统玩完，(往往刚学的新手不知道)。
c)逼得大家选择Stringbuffer类来操作可变String，很不方便。
循环里面用String也是可以的，JAVA的GCJVM会自己调，但有必要的话也可以在程序里手动调GC回收内存。JAVA底层控制弱这没办法，毕竟隔了层JVM，上JNI调C吧。
感觉LZ看问题实在是很偏颇啊，JAVA本身的优势在于稳定性（靠JVM），简单易学（没有指针这些容易让初学者绕晕脑袋的东西）和丰富的资源（开源）。事实证明，JAVA是成功的，1.）JVM实现了跨平台的同时也保证了系统的安全性，你代码漏洞再大也顶多把JVM弄崩溃，OS还是好好的，为此，付出一点性能代价是可以接受的。2.）简单易学意味着能快速的培养大批coder，意味着使用JAVA的公司能用相对便宜的价格招到开发人员，这意味着开发成本降低。

[解决办法]
mark
[解决办法]

探讨

扯蛋！！！随便写点儿东西就充高手，粘个纸鼻子就楞装大象了。

[解决办法]
有道理?没道理?
[解决办法]
相比较java还是很简单的，虽然不像C/C++那样有艺术性，
[解决办法]
听不懂~~~~~~~~~~~~~~~~~~~~~顺便顶一下
[解决办法]
顶起楼主
[解决办法]

探讨

[size=24px]老是在这里说些JAVA不好的话，哎，应该封号！！[/size]

[解决办法]

探讨

[size=24px]老是在这里说些JAVA不好的话，哎，应该封号！！[/size]

[解决办法]
還是看不懂,樓主向sun說說吧
[解决办法]
楼主觉得Java对底层控制的不好的话 把自己的青春贡献给JVM吧 保证你不后悔
[解决办法]
楼主的ｂｌｏｇ不错，以后经常去。
[解决办法]
没怎么看。

树业有专功。本就没有完美的东西。
说java烂，有觉得有点过了。

[解决办法]
你觉得 Java“烂”是因为你选错了开发语言和开发平台，不同的语言和平台适合不同的需求，语言无所谓烂与不烂，在一个平台上开发出的应用才有烂与不烂之分！
[解决办法]
Java“烂”ma?还好啊.
[解决办法]

探讨

"JAVA的公司能用相对便宜的价格招到开发人员，这意味着开发成本降低"

楼上，这个好象对过来了吧，同时java也比.net等难学多了。乱七八糟框架一堆。
价格上面，是不是反过来了啊？哈哈

[解决办法]

探讨

对于本楼问题，我测试了cache GBK字符集后，凡字符串都从cache里生成，这样内存只有一份就OK，但是我没想到的是，测试结果
告诉我，不能这样做。本来想占用少一内存，共享字符集，没想到适得其它反,使用时内存狂增！！
终于明白 java为什么不cache全部的 utf-16le字符集，而只是几面个英文字符集。

[解决办法]
说错了，是 U+0000～U+007F 的字符。
[解决办法]
充分说明你根本不了解JAVA的设计思想。
2 Long a = 2l; 
Long b = 2l; 
//结果为ture 
System.out.println(a == b); 
Long c = 128l; 
Long d = 128l; 
//结果为false 
System.out.println(c == d); 

就拿这个问题来说。Long对象可能的值有多少？那是一个天文数字，但为什么只cache了 -128到127？
int 值有2的32次方，为什么只调用ild_0到ild_9的10个直接指令？

其实这正是JAVA实现时CACHE原则的精妙之处。
个C

一个论坛，如果开上三年，贴子可能上千万，但常来论坛的人最常看的是哪些？
最近三天的，所以只要把最近三天的贴子放到内存中，这个CACHE原则就是非常正确的思想。
CACHE那些98%的人去浏览的2%的数据，这是UOP思想的正确应用。因为JVM不可能CACHE一个天文数字的可能，
那么CACHE最常用来的命中率最高的数据就是一个正确的设计思想。

整数指令不仅仅是数学运算，因为大量的数学运算CACHE根本不想作用，而更多的情况是牧举，标记，信号量等。
在这种情况下，根据一个正常的编程人员的思维，为0-9设计直接指令可以解决大多数情况，为Long cache 256个对象也可以解决大多数情况。


如果一个编程人员在使用两个互斥标记时不是用0和1，而是用994和995，肯定没有问题，但作为设计JVM的人在CACHE时要考虑有人不用0和1而用994和995，那这个人的脑子就和用994和995的程序员一样不正常。CACHE原则本身就是根据大多数人的习惯来设计的。

[解决办法]
你说的导致的 问题更是搞笑。
a)符串String 常量是无法确定的，如果在一个系统中使用过多的常量，会让内存涨破。 
b)不能在for等语句中使用String，这样容易让内存out，系统玩完，(往往刚学的新手不知道)。 
c)逼得大家选择Stringbuffer类来操作可变String，很不方便。 

这三个问题更说明你不懂JVM的实现。

字符串常量池在运行时被映射到方法帧中。如果一个方法帧内的字符串常量池太会溢出。那以前的任何语言一定溢出，因为之前的任何语言汇编成机器码的时候，所以字符串常量都会在方法调用栈中入口点上面的临时表中，而且相同内容的字符串分别保存。占用的空间比JVM的常量池更大，因为JVM的常量池是把内容相同的合并了。

JVM这种设计不但不会降低性能反而提高了性能，因为JAVA编译器比传统编译器更聪明。

第二个问题同样道理。

第三个问题更是因为你的无知而引起的。设计模式的作用如果用过程语法分析，就象分析一个国家的宏观经济时说街上张三麻子亏了一样。

按你说我COPY一个文件，要从用户模式到内核模式的7次切换，要从换到用户模式读写缓冲到内核模式的读写缓冲的4次COPY。这样作业系统最底层的设计也是很烂？大量浪费空间和性能？

当你自己不懂一种设计的核心思想时你没有资格说什么烂一，不客气地说实现JVM的人比你聪明多了，他们多少年来也在不断优化，你说的那些问题根本不是问题，仅仅是因为你自己不懂而已。一个小学生，他肯定说数学体系很烂，因为他认为整数多方便啊，加减乘除很快啊，还要弄个小数和，虚数之类的东西，浪费计算时间。
[解决办法]
你说的导致的 问题更是搞笑。
a)符串String 常量是无法确定的，如果在一个系统中使用过多的常量，会让内存涨破。 
b)不能在for等语句中使用String，这样容易让内存out，系统玩完，(往往刚学的新手不知道)。 
c)逼得大家选择Stringbuffer类来操作可变String，很不方便。 

这三个问题更说明你不懂JVM的实现。

字符串常量池在运行时被映射到方法帧中。如果一个方法帧内的字符串常量池太会溢出。那以前的任何语言一定溢出，因为之前的任何语言汇编成机器码的时候，所以字符串常量都会在方法调用栈中入口点上面的临时表中，而且相同内容的字符串分别保存。占用的空间比JVM的常量池更大，因为JVM的常量池是把内容相同的合并了。

JVM这种设计不但不会降低性能反而提高了性能，因为JAVA编译器比传统编译器更聪明。

第二个问题同样道理。

第三个问题更是因为你的无知而引起的。设计模式的作用如果用过程语法分析，就象分析一个国家的宏观经济时说街上张三麻子亏了一样。

按你说我COPY一个文件，要从用户模式到内核模式的7次切换，要从换到用户模式读写缓冲到内核模式的读写缓冲的4次COPY。这样作业系统最底层的设计也是很烂？大量浪费空间和性能？

当你自己不懂一种设计的核心思想时你没有资格说什么烂一，不客气地说实现JVM的人比你聪明多了，他们多少年来也在不断优化，你说的那些问题根本不是问题，仅仅是因为你自己不懂而已。一个小学生，他肯定说数学体系很烂，因为他认为整数多方便啊，加减乘除很快啊，还要弄个小数和，虚数之类的东西，浪费计算时间。
[解决办法]
基础科学发展到今天，那种到苹果园休息一下就砸一下然后发现一条举世公认的定理公理之类的神话已经不可能了。
如果有这种幻想，你只能怪自己没有生在创世纪的年代。

你玩一两天就发现的惊天秘密，其实都是别人早以发现然后经过研究又根本不算秘密的东西，人家悄悄地不说了。
在人类基础知识已经积累到一定体系的前提下我们只能老老实实地认识世界而不要以为自己能发现世界，也许经过多年的认识积累真的能有所发现，但绝对不是靠玩一两天就能发现别人没有发现的宝藏。


脚踏实地吧。
[解决办法]
有点意思，标记一下
各位继续，我对axman很景仰，呵呵

从这么一点（也许是有不适用的地方）说java就烂，有点过了，瑕不掩瑜阿！
[解决办法]
术业有专攻
Java 本身优势在于Java EE
不过也还是希望 Java 把存在的一些问题好好改进

查看更多 下一篇