tune部分段落翻译

大部分能看明白,表达不够明确或者相当错误,还请各位达人帮忙纠错

Chapter 1. 介绍
The trouble with doing something right the first time is that nobody appreciates how difficult it was.
--Fortune

第一次做事情遇到麻烦是因为没有人理解这事儿有多困难。

There is a general perception that Java programs are slow. Part of this perception is pure assumption: many people assume that if a program is not compiled, it must be slow. Part of this perception is based in reality: many erly applets and applications were slow, because of nonoptimal coding, initially unoptimized Java Virtual Machines(VMs), and the overhead of the language.

通常认为Java程序运行非常慢。这种理解是纯粹的假设:许多人假定如果一个程序没有被编译,它一定很慢。而这个理解又来自于现实:很多早期的applets和applications运行很慢,因为并非最佳的编码,没有优化的Java虚拟机,和间接的语言。

In earlier versions of Java, you had to struggle hard and compromise a lot to make a Java application run quickly. More recently, there have been fewer reasons why an application should be slow. The VM technology and Java development tools have progressed to the point where a Java application (or applet, servlet, etc.) is not particularly handicapped. With good designs and by following good coding practices and avoiding bottlenecks, applications usually run fast enough. However, the truth is that the first (and even several subsequent) versions of a program written in any language are often slower than expected, and the reasons for this lack of performance are not always clear to the developer.

早期版本的Java,程序员们不得不努力地并做出很多妥协让Java application快速运行。最近,只有很少的原因使程序运行变慢。虚拟机技术和Java开发工具的发展使得Java程序并不存在显著的缺陷。通过良好的设计并遵循良好的编码规范并避免瓶颈的出现,程序通常运行得足够快。然而,事实上第一个(甚至之后的几个)用任何语言说编写的程序的运行通常都比预期的要缓慢,导致缺乏性能的原因并不是每个开发人员都清楚。

This book shows you why a particular Java application might be running slower than expected, and suggests ways to avoid or overcome these pitfalls and improve the performance of your application. In this book I've gathered several years of tuning experiences in one place. I hope you will find it useful in making your Java application, applet, servlet, and component run as fast as you need.

本书说明了为什么某个特定的Java应用程序可能运行得比预期的要慢,并提出了一些避免或者克服这些缺陷并提升应用性能的方法。本书中,我已经在一个地方搜集了数年的调整经验。我希望这对使你的Java应用程序,applet, servlet和组件运行更快有帮助。

Throughout the book I use the generic words "application" and "program" to cover Java applications, applets, servlets, beans, libraries, and really any use of Java code. Where a technique can be applied only to some subset of these various types of Java programs, I say so. Otherwise, the technique applies across all types of Java programs.

本书所有内容,我使用了一般性的词组"application"和"program"来代替Java应用程序,applets, servlets, beans, libbraries, 和所有实际的任何Java代码的应用。这个技术可应用到Java程序的一些子集中。另外,该技术适用于所有类型的Java程序。

1.1 Why Is It Slow?
This question is always asked as soon as the first tests are timed:"Where is the time going? I did not expect it to take this long." Well, the short answer is that it's slow because it has not been performance-tuned. In the same way the first version of the code is likely to have bugs that need fixing, it is also rarely as fast as it can be. Fortunately, performance tuning is usually easier than debugging. When debugging, you have to fix bugs throughtout the code; in performance tuning, you can focus your effort on the few parts of the application that are the bottlenecks.

它为什么这么慢?这个问题经常在第一次测试后就被问及:“这些时间在干吗?我并不希望它花这么长时间。” 好,简短的回答是它这么慢是因为它并没有被调整性能。即便这个代码的第一个版本可能有没有修复的bugs,它也可以以罕见的速度运行。幸运地是,性能调整通常比调试简单。调试时,你不得不去修复代码中所有的bugs;而在性能调整里,你只要集中注意,关注应用程序的少数几个方面,而这少数的方面往往就是瓶颈。

The longer answer? Well, it's true that there is overhead in the Java runtime system, mainly due to its virtual machine layer that abstracts Java away from the underlying hardware. It's also true that there is overhead from Java's dynamic nature. These overheads can cause a Java application to run slower than an equivalent application written in a lower-level language (just as a C program is generally slower than the equivalent program written in assembler). Java's advantages-namely, its platform-independence, memory management, powerful exception checking, built-in multithreading, dynamic resource loading, and security checks-add costs in terms of an interpreter,  garbage collector, thread monitors, repeated disk and network accessing, and extra runtime checks.

详细点儿的回答?那么,是不是真的有一套顶层的Java运行系统,主要由于它的虚拟机层将Java从底层硬件中抽象出来。它也确实间接地来自于Java的动态性。这些间接性导致Java应用程序比相对应地使用底层语言(比如C语言通常要比相对应汇编程序运行地慢)写的应用程序要运行地更慢。Java地优势,即平台无关性,内存管理,强大地异常检查,内建的多线程,动态资源加载,解释期间的安全检查的成本,垃圾收集,线程监视器,重复硬盘和网络访问,以及额外的运行时检查。

以下是对提供的参考资料的总结,按照要求结构化多个要点分条输出: 4G/5G无线网络优化与网规案例分析: NSA站点下终端掉4G问题:部分用户反馈NSA终端频繁掉4G,主要因终端主动发起SCGfail导致。分析显示,在信号较好的环境下,终端可能因节能、过热保护等原因主动释放连接。解决方案建议终端侧进行分析处理,尝试关闭节电开关等。 RSSI算法识别天馈遮挡:通过计算RSSI平均值及差值识别天馈遮挡,差值大于3dB则认定有遮挡。不同设备分组规则不同,如64T和32T。此方法可有效帮助现场人员识别因环境变化引起的网络问题。 5G 160M组网小区CA不生效:某5G站点开启100M+60M CA功能后,测试发现UE无法正常使用CA功能。问题原因在于CA频点集标识配置错误,修正后测试正常。 5G网络优化与策略: CCE映射方式优化:针对诺基亚站点覆盖农村区域,通过优化CCE资源映射方式(交织、非交织),提升RRC连接建立成功率和无线接通率。非交织方式相比交织方式有显著提升。 5G AAU两扇区组网:与三扇区组网相比,AAU两扇区组网在RSRP、SINR、下载速率和上传速率上表现不同,需根据具体场景选择适合的组网方式。 5G语音解决方案:包括沿用4G语音解决方案、EPS Fallback方案和VoNR方案。不同方案适用于不同的5G组网策略,如NSA和SA,并影响语音连续性和网络覆盖。 4G网络优化与资源利用: 4G室分设备利旧:面对4G网络投资压减与资源需求矛盾,提出利旧多维度调优策略,包括资源整合、统筹调配既有资源,以满足新增需求和提质增效。 宏站RRU设备1托N射灯:针对5G深度覆盖需求,研究使用宏站AAU结合1托N射灯方案,快速便捷地开通5G站点,提升深度覆盖能力。 基站与流程管理: 爱立信LTE基站邻区添加流程:未提供具体内容,但通常涉及邻区规划、参数配置、测试验证等步骤,以确保基站间顺畅切换和覆盖连续性。 网络规划与策略: 新高铁跨海大桥覆盖方案试点:虽未提供详细内容,但可推测涉及高铁跨海大桥区域的4G/5G网络覆盖规划,需考虑信号穿透、移动性管理、网络容量等因素。 总结: 提供的参考资料涵盖了4G/5G无线网络优化、网规案例分析、网络优化策略、资源利用、基站管理等多个方面。 通过具体案例分析,展示了无线网络优化中的常见问题及解决方案,如NSA终端掉4G、RSSI识别天馈遮挡、CA不生效等。 强调了5G网络优化与策略的重要性,包括CCE映射方式优化、5G语音解决方案、AAU扇区组网选择等。 提出了4G网络优化与资源利用的策略,如室分设备利旧、宏站RRU设备1托N射灯等。 基站与流程管理方面,提到了爱立信LTE基站邻区添加流程,但未给出具体细节。 新高铁跨海大桥覆盖方案试点展示了特殊场景下的网络规划需求。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值