.NET框架深度探索：CLR via C# 第4版

需积分: 9 34 浏览量更新于2024-07-19 收藏 6.98MB PDF 举报

"CLR via C#（第4版）——深入理解.NET Framework 4.5及多核编程" 《CLR via C#（第4版）》是面向.NET Framework 4.5和多核编程的权威指南，由知名作者Jeffrey Richter撰写。这本书旨在帮助开发者深入探索公共语言运行时（CLR）、C#编程语言以及.NET开发的各个方面。在第四版中，作者特别关注了多核编程，这是一个在现代计算环境中至关重要的主题。本书内容全面，覆盖了以下关键知识点： 1. **公共语言运行时（CLR）**：CLR是.NET Framework的核心，负责管理代码的执行，包括垃圾收集、类型安全、异常处理和代码访问安全性。书中详细阐述了CLR的工作原理，如何利用它来优化应用程序性能，以及如何理解和利用它的各种服务。 2. **C#语言深度解析**：除了介绍基本的语法和特性外，本书还涵盖了C#的高级特性，如泛型、委托、事件、匿名方法、Lambda表达式、异步编程（async/await）、动态类型等，并讨论了它们在实际开发中的应用。 3. **.NET框架**：探讨了.NET Framework的类库，包括基础类库、ASP.NET、Windows Forms、WPF、WF工作流和WCF通信框架等。读者将了解到如何有效地使用这些框架组件构建高效、可扩展的应用程序。 4. **多核编程**：随着硬件的发展，多核处理器已经成为主流。本书深入讲解了如何设计和实现并发和并行算法，利用多核处理器提升应用程序的性能。涵盖了线程、任务、锁、信号量、条件变量、线程池、异步编程模型等概念。 5. **内存管理与性能优化**：探讨了CLR的内存管理机制，包括垃圾收集的工作原理、对象生命周期管理以及如何减少GC开销。此外，还介绍了性能分析工具的使用，帮助开发者诊断和优化代码性能。 6. **代码调试与异常处理**：讲解了.NET框架下的调试技术，包括断点、监视、调用堆栈等，以及如何有效地处理和预防运行时异常，确保程序的稳定性和可靠性。 7. **安全性与互操作性**：介绍了.NET的安全模型，包括代码访问安全性和基于角色的安全性，以及如何与非托管代码（如C++/COM）进行交互，实现.NET与其他平台的互操作。 8. **设计模式与最佳实践**：探讨了适用于.NET开发的设计模式，以及编写高质量、可维护代码的最佳实践，帮助开发者提升代码质量。《CLR via C#（第4版）》是.NET开发者不可或缺的参考资料，无论你是初学者还是经验丰富的开发人员，都能从中受益匪浅，深化对.NET Framework的理解，提高开发效率和代码质量。

When Main makes its first call to WriteLine, the JITCompiler function is called. The

JITCompiler function is responsible for compiling a method’s IL code into native CPU instructions.

Because the IL is being compiled “just in time,” this component of the CLR is frequently referred to as a

JITter or a JIT compiler.

Note If the application is running on an x86 version of Windows or in WoW64, the JIT compiler

produces x86 instructions. If your application is running as a 64-bit application on an x64 version of

Windows, the JIT compiler produces x64 instructions. If the application is running on an ARM version

of Windows, the JIT compiler produces ARM instructions.

When called, the JITCompiler function knows what method is being called and what type defines

this method. The

JITCompiler function then searches the defining assembly’s metadata for the called

method’s IL. JITCompiler next verifies and compiles the IL code into native CPU instructions. The

native CPU instructions are saved in a dynamically allocated block of memory. Then,

JITCompiler

goes back to the entry for the called method in the type’s internal data structure created by the CLR

and replaces the reference that called it in the first place with the address of the block of memory

containing the native CPU instructions it just compiled. Finally, the

JITCompiler function jumps to

the code in the memory block. This code is the implementation of the

WriteLine method (the version

that takes a String parameter). When this code returns, it returns to the code in Main, which

continues execution as normal.

Main now calls WriteLine a second time. This time, the code for WriteLine has already been

verified and compiled. So the call goes directly to the block of memory, skipping the

JITCompiler

function entirely. After the

WriteLine method executes, it returns to Main. Figure 1-5 shows what the

process looks like when WriteLine is called the second time.

www.it-ebooks.info

FIGURE 1-5 Calling a method for the second time.

A performance hit is incurred only the first time a method is called. All subsequent calls to the

method execute at the full speed of the native code because verification and compilation to native

code don’t need to be performed again.

The JIT compiler stores the native CPU instructions in dynamic memory. This means that the

compiled code is discarded when the application terminates. So if you run the application again in the

future or if you run two instances of the application simultaneously (in two different operating system

processes), the JIT compiler will have to compile the IL to native instructions again. Depending on the

application, this can increase memory consumption significantly compared to a native application

whose read-only code pages can be shared by all instances of the running application.

For most applications, the performance hit incurred by JIT compiling isn’t significant. Most

applications tend to call the same methods over and over again. These methods will take the

performance hit only once while the application executes. It’s also likely that more time is spent inside

the method than calling the method.

Console

JITCompiler

Native CPU

instructions

static void Main() {

Console.WriteLine(“Hello”);

Console.WriteLine(“Goodbye”);

}

Managed EXE

static void WriteLine()

(remaining members)

...

static void WriteLine(string)

ITCompiler

unction {

}

SCo

rEE.

dll

1. In the assembly that implements the type

(

Conso

), look up the metho

iteLine

)

being called in the metadata.

2. From the metadata, get the IL for this method.

3. Allocate a block of memory.

4. Compile the IL into native CPU instructions;

the native code is saved in the memo

allocated in step 3.

5. Modify the method’s entry in the Type’s table so

that it now points to the memory block allocated

in step 3.

6. Jump to the native code contained inside the

memor y block .

bly that implements t

, look up the method (

Writ

alled in the

the metadata, get the IL for this me

ate a block of mem

pile the IL into native CPU instruction

ative code is saved in the memory

ated in

fy the method’s entry in the Type’s t

now points to the memory block a

e native code contained in

Native

www.it-ebooks.info

You should also be aware that the CLR’s JIT compiler optimizes the native code just as the back end

of an unmanaged C++ compiler does. Again, it may take more time to produce the optimized code,

but the code will execute with much better performance than if it hadn’t been optimized.

There are two C# compiler switches that impact code optimization:

/optimize and /debug. The

following table shows the impact these switches have on the quality of the IL code generated by the

C# compiler and the quality of the native code generated by the JIT compiler:

Compiler Switch Settings C# IL Code Quality JIT Native Code Quality

/optimize- /debug-

(this is the default)

Unoptimized Optimized

/optimize- /debug(+/full/pdbonly) Unoptimized Unoptimized

/optimize+ /debug(-/+/full/pdbonly) Optimized Optimized

With /optimize-, the unoptimized IL code produced by the C# compiler contains many

no-operation (NOP) instructions and also branches that jump to the next line of code. These

instructions are emitted to enable the edit-and-continue feature of Visual Studio while debugging and

the extra instructions also make code easier to debug by allowing breakpoints to be set on control flow

instructions such as

for, while, do, if, else, try, catch, and finally statement blocks. When

producing optimized IL code, the C# compiler will remove these extraneous NOP and branch

instructions, making the code harder to single-step through in a debugger as control flow will be

optimized. Also, some function evaluations may not work when performed inside the debugger.

However, the IL code is smaller, making the resulting EXE/DLL file smaller, and the IL tends to be easier

to read for those of you (like me) who enjoy examining the IL to understand what the compiler is

producing.

Furthermore, the compiler produces a Program Database (PDB) file only if you specify the

/debug(+/full/pdbonly) switch. The PDB file helps the debugger find local variables and map the IL

instructions to source code. The

/debug:full switch tells the JIT compiler that you intend to debug

the assembly, and the JIT compiler will track what native code came from each IL instruction. This

allows you to use the just-in-time debugger feature of Visual Studio to connect a debugger to an

already-running process and debug the code easily. Without the

/debug:full switch, the JIT compiler

does not, by default, track the IL to native code information which makes the JIT compiler run a little

faster and also uses a little less memory. If you start a process with the Visual Studio debugger, it forces

the JIT compiler to track the IL to native code information (regardless of the

/debug switch) unless you

turn off the Suppress JIT Optimization On Module Load (Managed Only) option in Visual Studio.

When you create a new C# project in Visual Studio, the Debug configuration of the project has

/optimize- and /debug:full switches, and the Release configuration has /optimize+ and

/debug:pdbonly switches specified.

For those developers coming from an unmanaged C or C++ background, you’re probably thinking

www.it-ebooks.info

about the performance ramifications of all this. After all, unmanaged code is compiled for a specific

CPU platform, and, when invoked, the code can simply execute. In this managed environment,

compiling the code is accomplished in two phases. First, the compiler passes over the source code,

doing as much work as possible in producing IL. But to execute the code, the IL itself must be compiled

into native CPU instructions at runtime, requiring more non-shareable memory to be allocated and

requiring additional CPU time to do the work.

Believe me, since I approached the CLR from a C/C++ background myself, I was quite skeptical and

concerned about this additional overhead. The truth is that this second compilation stage that occurs

at runtime does hurt performance, and it does allocate dynamic memory. However, Microsoft has done

a lot of performance work to keep this additional overhead to a minimum.

If you too are skeptical, you should certainly build some applications and test the performance for

yourself. In addition, you should run some nontrivial managed applications Microsoft or others have

produced, and measure their performance. I think you’ll be surprised at how good the performance

actually is.

You’ll probably find this hard to believe, but many people (including me) think that managed

applications could actually outperform unmanaged applications. There are many reasons to believe

this. For example, when the JIT compiler compiles the IL code into native code at runtime, the compiler

knows more about the execution environment than an unmanaged compiler would know. Here are

some ways that managed code can outperform unmanaged code:

• A JIT compiler can determine if the application is running on an Intel Pentium 4 CPU and

produce native code that takes advantage of any special instructions offered by the Pentium 4.

Usually, unmanaged applications are compiled for the lowest-common-denominator CPU and

avoid using special instructions that would give the application a performance boost.

• A JIT compiler can determine when a certain test is always false on the machine that it is

running on. For example, consider a method that contains the following code:

if (numberOfCPUs > 1) {

...

}

This code could cause the JIT compiler to not generate any CPU instructions if the host

machine has only one CPU. In this case, the native code would be fine-tuned for the host

machine; the resulting code is smaller and executes faster.

• The CLR could profile the code’s execution and recompile the IL into native code while the

application runs. The recompiled code could be reorganized to reduce incorrect branch

predictions depending on the observed execution patterns. Current versions of the CLR do not

do this, but future versions might.

These are only a few of the reasons why you should expect future managed code to execute better

than today’s unmanaged code. As I said, the performance is currently quite good for most applications,

and it promises to improve as time goes on.

www.it-ebooks.info

If your experiments show that the CLR’s JIT compiler doesn’t offer your application the kind of

performance it requires, you may want to take advantage of the NGen.exe tool that ships with the .NET

Framework SDK. This tool compiles all of an assembly’s IL code into native code and saves the resulting

native code to a file on disk. At runtime, when an assembly is loaded, the CLR automatically checks to

see whether a precompiled version of the assembly also exists, and if it does, the CLR loads the

precompiled code so that no compilation is required at runtime. Note that NGen.exe must be

conservative about the assumptions it makes regarding the actual execution environment, and for this

reason, the code produced by NGen.exe will not be as highly optimized as the JIT compiler–produced

code. I’ll discuss NGen.exe in more detail later in this chapter.

In addition, you may want to consider using the

System.Runtime.ProfileOptimization class.

This class causes the CLR to record (to a file) what methods get JIT compiled while your application is

running. Then, on a future startup of your application, the JIT compiler will concurrently compile these

methods using other threads if your application is running on a machine with multiple CPUs. The end

result is that your application runs faster because multiple methods get compiled concurrently, and

during application initialization instead of compiling the methods just-in-time as the user is interacting

with your application.

IL and Verification

IL is stack-based, which means that all of its instructions push operands onto an execution stack and

pop results off the stack. Because IL offers no instructions to manipulate registers, it is easy for people

to create new languages and compilers that produce code targeting the CLR.

IL instructions are also typeless. For example, IL offers an

add instruction that adds the last two

operands pushed on the stack. There are no separate 32-bit and 64-bit versions of the

add instruction.

When the

add instruction executes, it determines the types of the operands on the stack and performs

the appropriate operation.

In my opinion, the biggest benefit of IL isn’t that it abstracts away the underlying CPU. The biggest

benefit IL provides is application robustness and security. While compiling IL into native CPU

instructions, the CLR performs a process called verification. Verification examines the high-level IL code

and ensures that everything the code does is safe. For example, verification checks that every method

is called with the correct number of parameters, that each parameter passed to every method is of the

correct type, that every method’s return value is used properly, that every method has a return

statement, and so on. The managed module’s metadata includes all of the method and type

information used by the verification process.

In Windows, each process has its own virtual address space. Separate address spaces are necessary

because you can’t trust an application’s code. It is entirely possible (and unfortunately, all too common)

that an application will read from or write to an invalid memory address. By placing each Windows

process in a separate address space, you gain robustness and stability; one process can’t adversely

affect another process.

www.it-ebooks.info

剩余812页未读，继续阅读

qq_28643715

粉丝: 0
资源: 2

.NET框架深度探索：CLR via C# 第4版

CLR via C#, 4th Edition

NET CLR via C#(第4版)中文版（百度网盘链接地址）

.NET CLR via C#(第4版) 最新完整版 高清文字版

CLR_via_CSharp:通过C＃进行CLR第四版

CLR via C# 4th

clr-via-csharp-4th-edition-code（clr-via-c#第四版源代码）

CLR via C# 4th源码

CLR via C#,4th

CLR Via C# 4th 书籍源码

CLR via C# 4th Edition.pdf

最新资源

.NET CLR via C#(第4版) 最新完整版高清文字版